I don't think IRL identities are necessary for what I imagine. It's more like establishing a basic set of packages that have been around, have communities of committers, reverse dependencies, etc.
Maybe we would even make a starting assumption that the transitive closure of dependencies originating with a set of high profile packages are "approved".
I'm thinking aloud but I think there could be a reasonably pragmatic way to get this started...
it's been at least 5 years since npm started getting scrutiny relating to security weaknesses https://blog.andyet.com/2012/03/08/compromising-the-integrit...
and 4 years since Rubygems was compromised http://blog.rubygems.org/2013/01/31/data-verification.html
and yet, I don't see substantial movements relating to package security and trustability in these repo's. To be clear I'm not suggesting these two are any worse than others, they're just large repo's who have had incidents in the past.
The problem here (to my view) is that increasing the security of package repo's will slow down releases (additional checks take time) and cost money (additional security, hosting etc) and until there's a market demand for those service, they won't happen.
I'd agree that a curated small package repository would be a better way to address the problem, but the market doesn't seem very interested in that as a solution.