In your example having a self signed certificate would be worthless. If someone
is performing a Man In The Middle attack on your users then they can also
sign their own certificate while impersonating your site. Without
verification your users would not know the connection to your site is
compromised.
While the current system is not ideal, you should not try to completely do
away with verification.
Passive MITM is MUCH higher risk in the wild than active MITM. Active MITM also generally disrupts service or otherwise leaves evidence, so it eventually gets found; passive can go on forever.
The best thing would be opportunistic encryption, possibly using cached keys, for all traffic, combined with endpoint authentication (and maybe multiple levels, like SSL, SSL-EV, SSL-Real-Authentication-By-Humans) on top of that. Ideally, as close as possible as end to end, but if some security wasn't end to end, it might still be useful (i.e. various wireless and wired lan security protocols).
Don't forget too that most browsers will poll the user whether to accept a self-signed cert for the page the user's trying to load, but will simply fail when a service in that page tries to pull data over SSL from a domain with a self-signed cert. Flash, JS, etc.
I've been experimenting recently with spreading out databases geographically and letting clients (and to a lesser extent, DNS) do the bulk of the load balancing on data-intensive projects. I've gotten some great results. But right now, users would have to pre-visit a page at each data site and approve it in the browser. Or I could get a massively expensive wildcard cert and then make A-records for each of those sites, but I'd rather just access them straight through their IP addresses for speed.
The whole thing just irks me. All I want to do is make sure this line is encrypted between the end user and their ISP. That should be mandatory these days; but instead I have to pay for a cert on every single DB server?!
Your definition of "worthless" seems pretty hyperbolic. It would protect against some attacks, just not all attacks. The status quo for most pages is to protect against no attacks, so it would be an improvement. Nobody is suggesting that we should do away with verification — but for pages where we aren't doing verification anyway, that doesn't mean we should do away with encryption too.
Yes it's vital to security, but it's one of two components here that should be separated. The encryption itself is crucial to a lot of applications now that simply can't be spoofed. That wasn't really true 20 years ago. But now, just to achieve most kinds of load balancing you need a wildcard cert, and while there's obviously no reason that should cost 10x a single subdomain cert, there's also no obvious reason that the verification itself should be tied to the encryption.
Encryption is good, in and of itself, with or without verification for most security purposes. MitM attacks can happen just as easily if someone fails to notice that there's no little padlock in their URL bar. It's a separate issue, and one shouldn't have to pay a corrupt mafia for access to browsers' encryption capabilities if all you're looking for to secure your users.
You calling it a separate issue because you think about it that way doesn't change the fact that in terms of the current security model for the web... they're very intrisically tied together.
Do I think that RA/CA charging out the wazoo for the privilege of verified identity is right? No. That's what you need to be fighting against. You're trying to hack together some way to avoid buying a verified SSL by cutting corners. It's just not going to work.
In your example having a self signed certificate would be worthless. If someone is performing a Man In The Middle attack on your users then they can also sign their own certificate while impersonating your site. Without verification your users would not know the connection to your site is compromised.
While the current system is not ideal, you should not try to completely do away with verification.