I have to say I'm not really keen on the extra context switches required for these to do regular work (xbox suffers a bit there and so many apis seem to create threads that aren't IMHO entirely necessary sometimes), I would prefer if the AddThread just created a single thread that knew how to do both of these tasks.
The Xbox360 used a ThreadTaskManager instead of a SpecializedTaskManager once upon a time for that reason. Later, the loop-focused thread manager was improved and the SpecializedThreadManager started beating the ThreadTaskManager alone on the Xbox360 by a little bit in my performance tests at the time.
If desired, you can swap back to just using the ThreadTaskManager by setting the Space.ThreadManager = new ThreadTaskManager(). The performance should be pretty similar on the Xbox360.
An ideal situation would allow me to have my existing threads call the Bepu work helper functions when they reach a natural stopping point where they would otherwise wait for an event, but I can see how that would complicate the task distribution logic.
Custom managers are pretty easy to implement if desired. An example is the ThreadManagerTPL which uses the .NET task parallel library to do loops. The thread manager just needs to be capable of handling forloops and individual parallel tasks (though loops are guaranteed to never get called by BEPUphysics while regular BEPUphysics-spawned parallel tasks are in progress).
As far as performance goes, though, it will likely be a bit hard to beat the SpecializedThreadManager (especially on the PC). The loop-focused manager has extremely cheap and effective load balancing and very low overhead (which is good, because the majority of the engine is big forloops).