This would basically be a high-performance HTTP server coupled with an embedded Python interpreter. Instead of running Django in Python, it would take your app's settings.py and url.py and compile the URLs you have into a DFA, using a high-performance regexp implementation like re2. When a pattern matches, you could either register your handlers in Python or in C++. Python handlers would work like Django normally does: they invoke a Python function, pass in request/response objects (constructed quickly via a C++ native HTTP parser), and write the response back to the socket. C++ handlers would invoke a C++ class to do the processing, which would use native C++ DB bindings or RPC stubs. C++ code should be able to call into the Python code via the normal interpreter mechanisms, so you can share utility functions between them. (Vice versa as well, though writing Python bindings for C++ utilities might be a bit more of a chore.)
The templating language could also be redone to parse the templates on server reload, generate bytecode, and then read directly from C++ data structures or Python wrappers around those. Then rendering the template becomes a very quick linear pass over the bytecode, either outputting to a buffer or directly doing zero-copy vectored IO to the socket.
The cool thing about this (other than the extra speed from using good algorithms and writing the framework in a fast language) is that you could incrementally transition from a productivity-focused startup webapp to a performance-focused high-growth webapp. You don't need to write everything in C++; only the most frequently trafficked dynamic pages. Oftentimes webapps have very sharp hotspots, eg. I'm guessing that the front page of HN gets many times more pageviews than /new, /leaders, or /reply. If they're static you can cache them, but oftentimes the heavily-trafficked pages are heavily trafficked because they change frequently.
The other cool thing is that it preserves a built-in framework for prototyping and experimentation that can re-use functionality you've built for the production site. Usually the experimentation process doesn't stop when a company grows up: it's really important to provide an escape hatch for folks to try new ideas without having to rewrite everything you've built over time.