Absolutely not. An added bit of compile time is the least of your worries and if you really don't want to compile stuff on production, look at packaging your virtualenv as a compiled deb/rpm.
Never ever ever mix/depend upon system packages in your virtualenv. Ever.
You're always depending on system packages somewhere. Compiling isn't the only reason - sometimes it's necessary just to make the damn thing work.
Some examples:
* PIL - Using Pip's version on Ubuntu, you have to hack your directory structure and re-compile the whole thing or PIL doesn't compile in support for your image libraries.
* psycopg2 - This is hit and miss (OS X comes to mind), but depending on the system version guarantees that it has been tested to work with the specific version of Postgres on your system.
* Crypto libraries - Broken packages have ended up on Pip and just cause a bloody headache. The system package is, again, tested and works.
Compiling a DEB/RPM would be a good idea, but it's not a well supported system at all. If there were a simple pip compile --type=deb or something, we would be all over it.
Psycopg2 - Well, it's just a client library - surely you will be making sure your client matches your server's version (whether that's local or a clust or whatever)? Sure your system will likely need Postgres headers installed, but why is that an issue? Actually, let me just check that. e: Yeah, you need libpq-dev installed, but I fail to see the point here? You need to make sure you have python-dev and a correct version of Python installed, too.
PyCrypto - Hmm, not had a problem with this hugely.
What I was suggesting doesn't involve a deb of individual packages, but a deb of the entire app/virtualenv.
Never ever ever mix/depend upon system packages in your virtualenv. Ever.