What we need is HTTPC, which would be SSL without verification. It would not show up as verified like HTTPS-- no green bar, etc. It would look just like HTTP, except with encryption.
They also offer extended validation and other paid options. I use them for wildcard certificates, which are normally at least $200 each. I've created nine wildcard certs since January 1, for a total cost of $50.
With a modification we could get a better system though. If we have a trusted third-party that has a CA certified certificate (we know we can trust them), we could ask them to contact the server on our behalf and forward us the certificate. This way we know that the certificate for the server is authentic. If we then cache the certificate we will not need to ask the third-party again. The problem with this system is would there actually be anyone who would want to run it, we would need to absolutely trust them, and there isn't really any monetary gain in it (for a service this size, you would need a company to back it, in all honesty), maybe some CA would do it.
So you can already use self-signed certificates, it is just users are given a large red screen with a tiny "trust it" button.
Given the ease of obtaining a root certificate, I'd say nowadays they're a great deal less deceptive than some CA-signed certificates. Visiting a site that has a self-signed cert doesn't prove your connection is safe. Visiting a site that has a CA-signed cert doesn't prove your connection is safe. What's the point of this exercise again?
I'm not sure at all what your second paragraph gives us. We don't need a fourth party to mediate the certification the third party gives us. The whole process of cert signing is a certification from a third party. That part actually works; the problem is that browsers accept signatures from organizations they should not, and the meta-problem is that there really isn't a solution to that problem. (What cert organization is secure against their local law enforcement?)