We've experienced the same problem in our .NET Winforms apps. Initially we overcame it by coding a 'robot' class that would open a form, find the appropriate controls and then operate on them. We would interrogate the form/database to verify the outcome was what we expected.
Argh. It works, after a fashion, but we couldn't devote the time necessary to make a really good robot tester, so it's not multithreaded and that creates some problems...
I've read recently about someone who put all GUI-based methods into a separate class. When he wires up the GUI, he just calls a method in another class that does stuff. I think this is one way to go, though I'm not sure about how you'll manage verifying GUI actions based on successful method calls. I suppose that as long as your GUI reacts to values returned from the class, you'll be fine.
We've resolved that on our next project, we will avoid GUI testing (by actually loading a form, that is) like the plague, by any means necessary.