One possible solution to this is to have a core group of maintainers verify the most popular packages. I place my trust in the maintainer and the maintainer signs a specific version of the package. This will not scale to 100% of the packages, but that is fine. As long as django, flask, psycopg2, etc. are signed I can take responsibility for reviewing django-pretty-snarfs-with-smiles myself. That is essentially our trust model with GitHub already: you blindly download large official looking projects but read through the code of small stuff (right?). Perhaps after a while some developers become trusted and get to have their signing process fast-tracked.
At the end of the day if I could have one improvement it would be a big fat warning that pip gives you that says "what you are about to install is likely malicious code. Do not do it without verifying that it is not by manually downloading it and reading the source."
BTW, simply running "pip install foo" will let foo's setup.py run arbitrary code on your machine. It is such a giant security hole by design that I cringe every time I have to use it.
Edit: another potential model is for PyPI to punt the verification onto outside entities, such as GitHub, Bitbucket, etc. Basically instead off building my packages on my (potentially compromised machine), I would tag a version of it on GitHub and instruct PyPI to build it. It is easy to establish trust between PyPI and GitHub, so the guarantee you get with PyPI is "this package came from exactly this source" where you can read the source before installing it. Like I said above, GitHub also has a trust model problem but this would reduce the amount of work one would need to do to verify a package from two places to one.