A real system to take care of this issue is possible.
There's a number of problems here, and each one needs to be addressed, but luckily none of them are really all that contradictory. I'll detail a practical system:
Problem 1: A random user needs to be able to connect into the verification system easily.
Solution: Handle this in the same way DNS is handled. When setting up your connection settings (IP address, DNS, etc), include a new setting such as 'SSL Verification Address Book' (henceforth referred to as SVAB). Since most people won't know this as they wouldn't know their DNS server, extend DHCP (the system that gives you your IP and DNS) to also give you a SVAB. The SVAB could be hosted by anyone, but would likely be hosted by your ISP.
Problem 2: A malicious user who is running the SVAB can change any details he wants, and send you his own crafted entries.
Solution: Instead of the SVAB returning the actual tokens, it will only provide the client with a list of 'SSL Verification Servers' (henceforth referred to as SVS). Each SVAB would be responsible for it's own list of SVS. When the client needs to verify a server, it will send a request for that site to all of the SVS in the list.
Problem 3: A malicious user who is running an SVS can change any details he wants, and send you his own crafted entries.
Solution: Since the client has a whole list of SVS, and will receive a response from each one, it will be very easy for the client to detect that an entry has been tampered with. To determine the correct entry, the client would simply go with the majority correct information, and display a warning. If the majority is less than some percentage (75%?), an error could be displayed instead of the warning.
Problem 4: A malicious SVAB could send you a list of SVS servers to which they have altered the entry across all of the SVS servers.
Almost Solution: If a policy is implemented in the client where the servers must come from some minimum number of top level domains, or class B internet routable IP addresses, then the task of setting up the malicious SVS servers could be made extremely difficult. In addition, your SVAB would nearly always be hosted by your ISP - and if you do not trust your ISP, you could switch to a new one. MITM attacks between you and your ISP could be possible as well, but the risk could hopefully be minimized - possibly by your ISP or trusted host for your SVAB providing you with a secure key.
Problem 5: Registering your site with the many SVS servers.
Solution: There's a number of possibilities here: a first come first serve basis whereby you would register your site with one node, and that node would propagate your certificate to other nodes as long as the entry does not already exist. Alternatively, the internet site itself could host it's key (http://internetsite/svskey) and each SVS would be in charge of retrieving the key itself, and caching it. If the key on the internet site changed, a second key might be provided in the previous key to validate the new key. At any rate, this problem should not be too difficult and I believe the internet site hosting it's own key would be by far the best solution as it would make it very easy to set up for the internet site.
So to summarize, you would have a SVAB entry in your internet settings which could be entered manually or automatically via DHCP. This SVAB would provide a list of diverse SVS, which would all be queried by the client. The majority response from the SVS servers would be considered the correct one. Registering your own internet site would be easily done by uploading a special key file.
I believe this takes care of the main fear of TFA, which is that you have to trust someone permanently. In this case, you would only have to truly trust your chosen SVAB to create a very good list of SVS servers. This system would also have the advantage of being particularly easy to implement, as well.
