A fully-featured browser is used in a VPS. The video/graphics output is shown on my local PC.

Is there anything that can be done to make it extremely difficult for the provider of the VPS to see the output graphics of the browser?

Is there anything that can be done to hide the IP and domain name of the site too, that the browser is browsing?

A vps, including the frame buffer for its graphics, is just a process running on a host. So there isn't much that can be hidden from someone on the host who is determined. Even if you run the browser remotely the host could still record the packets and reconstruct the session. Access to the guest means access to things like ssh keys also. You can make it harder but I don't think you could be 100% safe.

What are the commonest tools the provider would use if they wanted to read the frame buffer, the ssh keys and packets? Anything that beats such tools is good enough for me.

Can't the frame buffer be remote, located in my PC? With remote control software, where is the frame buffer?

The V in VPS stands for virtual meaning your server isn't a "ring 0" process to start with. Since you can not "see" anything below your own process level the only logical conclusion is you have no control whatsoever. If that irks you enough to spend cash then IMHO the only way to go is (colocating) your own properly secured physical server.

Could use vmware in the VPS. And the guest could be OpenBSD or Windows so linux tools running in the host do not work. And the VM could use full disk encryption so its disk image cannot be modified without invalidating it.

If a VPS is set up this way and everyone here is given full control (ie I tell you the root password) but NOT tell you the password of the guest root, nor the FDE passphrase, what can you guys do to break into the VM, in order to find out what site it is connecting to through TOR?

You can't reconstruct the session by recording the packets because TOR is used.

You can't mess with the vmware disk image without damaging it - it is encrypted by the guest (full disk encryption).

You can't attach to processes in the guest with debugging tools because you cannot see individual guest processes, not to mention they are OpenBSD or Windows processes.

You can't use the vmrun backdoor because you do not know the guest passwords.

You can't use a keylogger because no keyboard is being used in the VPS - I am connecting to the VM, with RDP or X through SSL/TLS.

What can you do? And crucially, what can I do as a countermeasure?

I would just wait until you start the VM, at that moment the disk is accessible and the VPS hoster can make an image of it. You can make it harder, but you can't prevent that the VPS hoster get access to everything on the machine. There is nothing that you can do about it but (as unSpawn already said) not using a VPS, but a dedicated server instead.

How would you decrypt the image that you would make? Remember the vmware VM uses full disk encryption. It is as if a laptop with FDE has been stolen. Your only chance is a ram dump. You would need to develop special software to find where in the ram dump the encryption key resides, but VPS hosters are not developers.

If the VM is running access to the encrypted disk image is already granted. Nothing is preventing the provider from making a snapshot of the complete VM at this state, so that the problem of a missing password or keyfile simply doesn't exist.

Ram could be encrypted too I just found out, in an OpenBSD VM:

http://security.stackexchange.com/a/8299

Still, the encryption keys have to be stored in RAM or CPU registers and it is no problem at all for a VPS host to get those keys.

You haven't addressed that not everybody is a developer. VPS hosters are usually not. It is not trivial to find the keys.

When novelty wears out, maybe there will be off-the-self software to break OpenBSD's ram encryption by finding the key, but not for a while, and not for low value targets like my rear.

VPS hosters usually employ some developers, so I wouldn't rely on that. Anyways, a security concept that relies on the attacker not being a developer or that a key is hard to find (security by obscurity) is a broken security concept.

With this rationale TOR is broken security because it relies on three nodes not colluding with each other.

And when you visit your bank site, you rely on no one being interested in doing MITM on your connection.

Tor is broken security, since you have to trust the first and last server in the chain to not be compromised. And yes, when doing online banking you have to make sure that you are not victim of a man in the middle attack.
Security by obscurity was never and will never be safe.

The fact that TOR and almost all security used worldwide is broken is off-topic when additions to TOR are being looked for. Additions to TOR might as well be just as imperfect as TOR. Nothing to lose.