Mixing pip and debs loses some of the advantages of having a standard system, though. I think you're better off producing deb packages from PyPI in your build server.
I typically rec installing virtualenv systemwide, if a reasonable version is available by package, and managing per-app dependencies in a requirements.txt that's platform agnostic.
The Debian ecosystem is great, but I would never recommend a developer marry an app to it.
But there's no reason you can't have the cake and eat it too; you can create a virtualenv from a requirements.txt file on your build server, then package it up in a deb package that installs those files in a custom directory (not in the shared Python modules path).
That way, you get static artifacts you can deploy (instead of deploying using pip, which requires compiling any non-pure-python package on the server), you get to use apt's dependencies for non-Python packages, like system libraries, and you can easily rollback by simply pushing the previous version of the deb package, which is cleaner than rolling back with pip, in my experience.
