I just recently added the combined forums feed as an item on my customized Google home page which is how I ended up seeing your post. I only qualify my own post this way because I am most likely the first of many on what may very well become a long thread. While I am on the topic of meandering, does anybody else notice that it is very hard to type into the rich text editor if you are on a machine under 1 ghz? I started typing this into the RTF editor on the forum topic post page, but ended up switching to an outlook HTML message which doesn't have any lag. Very interesting, I thought that rtf editor lag was fixed.
In any event, back to the topic: migrating existing asp net applications to DotNetNuke. Great topic by the way. The simple answer is that all DNN Modules are are extended web user controls. The PortalModuleBase class (I am pretty sure that is what it is...) inherits (eventually) from Web User control, which means that you can easily create a simple web user control, add whatever references you want to it, and configure it manually as a module. With DNN 3.x & above, if that control lives anywhere in the DNN File System, you can configure it as a view control for a module.
Getting more, advanced, there are several routes you can take in adapting your old school monolithic application to DNN. One of these is to encapsulate all of your old application's page's functionality into web user controls, and then dynamically load them into a placeholder determined by a parameter in the query string. Many modules that you can download for free do this, unfortunately, the guy I learned this technique from has since turned his downloads into a fee based system. I have several modules on my site which you can access through my user profile which use this technique. I have read (on wwwcoder.com by Patrick Santry) an article describing this as the Dispatcher Pattern. The Document Management module free on my site for DNN3.x uses this pattern.
The second technique is to use I believe the navigateurl method to return a url to a specific named control in your module, but you will still have to tack anything you wish to pass onto that module into the rest of the navigateurl. (Learn more in the module developers guide). Several great examples of this include the Blog Module & the Gallery Module, although all of the core modules use this technique. I am personnally investigating if I should use this or my old technique in a series of modules I am about to start work on for my employer.
Your question regarding logons being able to access the site based upon tables in the SQL Database seemed to be two questions. The first, can you get at the data , the answer is yes, as of DNN 3.3, all user profile data is relatively easily accessible compared to the older M$ provided membership provider. I still haven't figured out if the old aspnet_ tables are required or being used to store the password, I don't know. But I do know it is a whole lot easier to manage user accounts programmatically or with SQL Stored Procedures, Triggers & Functions.
You need to dive deeper into the DotNetNuke Membership provider documentation for your other questions. Fortunately, this documentation is a free download on the DotNetNuke site. Also, I am pretty sure there is a link to a bunch of great DotNetNuke programming books, including the WROX Press book written by the Core Team. It's a great read, and provides in depth coverage of module development.
Happy Coding!