<p>From a programmer stuck in the web world...</p>

<p>What are the most common desktop development "frameworks" currently being used for desktop application development?</p>

<ol>
<li><p>Is it realistic to write desktop software for both Windows and OS X?</p></li>
<li><p>Is it realistic to use the same base code to write the business/data layers for an application that will have a partial web UI as well as a desktop UI?</p></li>
</ol>

Yes. You could use Java, Python/ Ruby etc with a cross platform UI framework, AIR etc etc.
Yes it is realistic. Build it on a client/server model and most of the code will fit either the desktop or web UI model.
If you went down the .NET root, you could use Silverlight for the web app, .NET server code for the backend and even Mono to enable you to develop for OS X.
If you took the Java route, Java runs within the browser, there is JavaFX coming soon that is a small flash-like version for browsers. It runs on just about all OS's and can handle the backend just fine.
Flex/ AIR offers an excellent way of developing desktop and web-based apps for OS X, Windows and Linux, but you'll need another language for the back-end. .NET, Java, PHP etc all work fine as the backend though.
Edit
At MrJeepster's request, here are details on interfacing an AIR frontend and .NET backend:
There are two ways you can interface AIR to a .NET backend: the DIY way and the remoting way.
The DIY way would involve defining your own (probably XML) data formats and using the low level HTTP request objects to communicate with a HTTP server, or even lower level socket classes to communicate with some other server.
The remoting way is all together easier as nice people have written a selection of free remoting packages:
http://www.adobe.com/devnet/flashremoting/articles/intro_flremoting_net.html
http://www.themidnightcoders.com/flashorb/gettingStarted.htm
http://www.fluorinefx.com/
Remoting involves sharing objects between the client and server. So you create some object on the AIR client, get the remoting framework to serialise it, transfer it to the server and deserialise it into a .NET object. The server then processes it and sends it, or a new object, back again via the same route.