Not sure if I am missing something here but I have written a lot of stored procedures with output parameters and coded them up using a standard DNN SqlDataProvider architecture and the ApplicationBlocks DLL that is used within DNN.

The trick is you have to use a prepared parameter set (think SqlParameter[4] parms = new SqlParameter[4]), mark the applicable parameter as output or input / output.  Then, in your code, you must process until the end of the recordset *then* you can get the output parameters.  If you trace the Sql calls in Profiler you'll see the output parameter declared as a temporary variable, the sp run, then the value selected - in this way it's more of a second result set. If you try and access the output parameter before the end of the resultset, you'll get a null value, because it's not there yet.

Rodney : just email me if you need some example code.  I've got it all built into my helper methods somewhere so I haven't had to think about it for a while.  You don't need to hack around and do funny stuff - it's all built in, just a little non-intuititve.

If you're building modules for distribution this will be far easier than having to bundle extra code or support a minimum feature set.