In answer to your questions:
1) No - SharePoint only knows or cares about SharePoint IIS websites; if an IIS website has not been extended, SharePoint does not interact with it.
2) Quite hard, IMHO.
Its easy, though the object model, to iterate through the various collections - SPWeb, lists etc. and persist that to file. For example, you could iterate through a SPSite's collection of SPWebs and dig out items from the Images gallery and/or the Pages list, and then persist that to the filesystem. But that won't get you a working site: you'll also need the Page Layout. That Page Layout will almost certainly have SP specific controls within it (e.g. field controls), and these will not work out of context. Then you have similar problems with your Master Pages, where (e.g.) your Menu controls won't work. Even if you did get all that sorted out, you would still have issues because a WCM page in MOSS is not just about content - webparts such as the Content Query or List View, which are used frequently in a WCM solution, would also not work. Finally, if you are really using the power of MOSS in your WCM solution, you will also be making use of custom lists, which won't translate particularly well to a non-SharePoint world.
You could, in a basic implementation, persist just the content (ie. the fields and the image files) to XML files on the filesystem, and then have a process which wrote that into your other WCM product's system. You could even do that via workflow if you put your mind to it, and there were web service interfaces on the remote WCM implementation. But it would be a fair amount of custom code, and you would be crippling your use of SharePoint to just basic web content, loosing out on the rest of the features in the stack.
Alternatively, your best bet in this scenario may be to use a simple screen scrape approach