I was actually once involved in working on a web app, which we eventually almost ended up marketing as a standard "desktop application". For some reason, Marketing got it into their heads that one of our major clients wanted the product to "appear to be a GUI application", so we created a little Windows app that just hosts the IE ActiveX control, and points to our web app (hiding the fact that it's actually a browser). So effectively, to an untrained eye it looked like the product was a standard GUI app.
Granted, this isn't exactly what you're asking (we were still pointing at a web app, and not hosting the whole thing locally) - but it's close enough. It would have been trivial - minus some of the remote web services it used - to set this up to just have the whole thing sitting on the local machine.
Here was the biggest problem though: look and feel. Especially feel.
People expect certain behaviours from rich GUI apps (drag and drop, native-feeling windows and dialogs, etc). It is extremely hard to get a genuinely native look and feel from a web frontend. There is simply a different user flow in what is expected when you open up a web app in a browser (eg. Gmail), as opposed to when you use a rich GUI application (eg. Outlook). In my experience, trying to equate the two is asking for trouble. If you put out a "GUI app" which acts like a web app, you're likely to be flooded with usability and LAF complaints.
TL;DR - Web apps and GUI apps have different looks and feels, and a different user culture to some extent. While it's technically possible to do something like this, from my experience, I wouldn't go there (again). At best you're likely to end up with a horrendous mix of client-side scripting that will be more difficult to learn, use and maintain than doing the whole thing as a normal GUI app in the first place. And people WILL complain about things "not quite feeling right" for a native GUI app. It's tempting to think that they won't - but they will.
I have never actually found a visual designer that makes it easy to create robust designs (if anyone has any they like, feel free to correct me). They are nice for dumping stuff on a fixed-size window to mock things up, but when it comes to making something that resizes nicely, plays well with DPI and themes, and all the other stuff that separates a professional UI from a merely "good-enough" one, they honestly become more work than just coding it up yourself (assuming a decent UI framework to play with).
Visual designers are excellent for rapidly prototyping software, trialling designs, and playing around to see how stuff looks, but I wouldn't use one for the final build.
Best Answer
Well - sort of, for buttons. But this might be harder than you imagine. These days the graphics used to represent GUI components aren't as simple as random bitmaps that are stretched (since these don't scale very well at all) - they're often vector based graphics with a lot of corner cases programmed into them (so when the button reaches the edge of the screen it may look slightly different, for instance.) And of course, you'll need different graphics when a button is clicked. For copyright reasons, developers often can't just use these existing graphics outright, so they have to be recreated - and while they do a good job for the most part, inevitably some things get missed given the huge array of graphical components out there. This is much less severe than it used to be - these days if I set the default platform look and feel in Swing, I notice very little that looks odd.
I'm saying all the above based on Swing, which is of course a lightweight, non-native GUI toolkit. You specifically mention SWT not looking native, which is a bit odd, because SWT is native. It's a toolkit that uses JNI underneath to call native components - so if something doesn't look right there, it's not going to be because of the look and feel.