Do you mean in your SQL Server Replication that data will be written directly to the Siebel base tables? If so then that is not a viable route. If the replication process will just read from the Siebel base tables that will be just fine. However, you will need some sort of translation from siebels contact data structure to dnn. Both Siebel and DNN spread out their contact data across several data and they do it differently. The mapping from one to the other is very doable but is not trivial so make sure you account for that time.

Another thing I will say is working with DNN, Oracle and SQL Server is straightfoward. Building a membership provider is reasonably straightforward (though no small task). However if you haven't worked with Siebel before you probably want to multiply your estimate time for various Siebel integration and configuration tasks by 2 or 3 at a minimum. Siebel is finicky, slow and has a bit of a learning curve. What seems like simple tasks can take much longer than anticipated as you figure out all the quirks and wrinkles. Make sure you have some Siebel expertise at hand to draw on. It's generally not something that you can just crack open the documentation and muddle your way through with no experience.

Another option:

If you want to use the Siebel as source db for authentication, check out the SSO open source module http://opensource.indyneinc.com/home/DevX/Articles/SingleSignOn/tabid/99/Default.aspx.  This custom module will let new user to log in, create account in DNN in real time.  It also has option to mass import users into DNN DB so you can assign users to DNN security roles (prior to user login the first time).  Notice that the module is based on SQLDataProvider but you could implement the OracleDataProvider replacements.

If need to mass import users from OLEDB support db (ie Oracle), check out the custom module http://www.workcontrol.com/Products/UserImport/tabid/103/Default.aspx