You will most likely need to write custom membership provider and profile provider for DotNetNuke. There are so many unknown details, its hard to explain.

One way to do this would be specify the landing page (done in host settings) for where the user goes after registering.  You could then write a custom module to put on this page.  The module you build would look at the new user registration and do whatever is necessary to create the user account on your non-dnn site.  You could then do something similar on your other site so when someone registers, it manually creates the dnn user account.  Of course, you need to make sure both your dnn and non-dnn sites have the same required registration fields.  You'll also want to consider ways to handle password and other profile changes so the systems stay in sync.

The larger problem I see is if someone goes from one site to the other, they may have to re-login (which I think was your real question).  You'll need to create some kind of single sign-on logic to handle this.  This is pretty easy to do if all your portals are dnn, but that's not your use case.  You may be able to make both sites use the dnn cookie, but I've never tested anything like that.  I would start by having the non-dnn site try to read the dnn authenication token to see if the user is logged in.  If so, process the login on your web app.  It may be a little harder to go the other way, but if it works in one direction, you can probably figure it out in reverse.  I'm not sure if you're web app will need a reference to dnn, but that may expose a few things.