Hi Gvdamn,
I'm not aware of any written guidance on this issue. It is a bit of an out-of-scope usage for DotNetNuke (which is designed to be a web application, not function as a Windows service). In addition to the configuration issues you have run into, you will also experience the occasional error due to a lack of httpContext. I do, however, know that this sort of thing is possible (because I've done it). However, I would classify it as an advanced activity, and due to the difficult-to-diagnose nature of the problems that result, it will be difficult to give the sort of highly-specific guidance that is most helpful.
When I refer to the DotNetNuke data provider metadata, I am referring to the configuration/dotnetnuke/data node. DotNetNuke needs access to this node in order to instantiate the correct provider (in this case, a SQL provider). When you leverage DotNetNuke outside of a web application, .NET will look for this in the associated app.config (either app.config or ExecutableFilename.exe.config). You'll need to add this key to that configuration file.
Due to the fickle method by which DotNetNuke instantiates a provider, it is likely that you will still run into errors after you've moved the key across. In this event, I suggest (a) linking to the source version of DotNetNuke so that you can step into the relevant functions (and see what is going awry), or (b) temporarily moving the relevant methods (e.g. DotNetNuke.Reflection.CreateObject) into your projects so you can trace into them without building the full DotNetNuke source package. Both methods are fine, but require some additional work.
Brandon