Extracting domain logic from the forms to which they are coupled?

Question

Many applications do nothing to separate the interface from domain logic. I’ve been programming for a couple decades and have worked at more than a dozen shops and none of them have taken any measure of separating the interface from the domain logic. That is, they're all using the Autonomous View pattern. This runs counter to all the wisdom I’ve read about separating concerns. When the user needs to choose an item from a set of items, that selection is directly tied to a combo box rather than an abstraction.

A huge drawback with all this coupling is that it makes it impossible to write unit tests. To run any unit tests the application in its entirety must first be loaded. In my mind, the use case should be encapsulated within an abstraction that can later have a database and an interface attached to it. This kind of separation would make implementing unit tests trivial by comparison.

Given that the average shop has its interface and domain logic tightly coupled, how to we refactor to separation? That is, a complete rewrite is off the table. What I’m talking about is taking a proposal to management about how to go about creating domain objects (whatever these happen to look like) that live in isolation from the database and the interface. In other words, it would be useful to be able to explain how this concept of presenting the user with a choice (something that is now represented by combos on forms) and to see how some methodology/framework/pattern represents that in an abstract sense and how that abstraction is then tied to the interface. This would make replacing combos with listboxes nothing more than a slight detail.

What are some good ways for extracting abstractions (domain use cases) from forms? Any good online resources? My current shop is on .NET, though I am interested in ideas from any development platform. Ultimately, what I need to provide is a concrete example (code) of how this might be accomplished.