Well, on windows you enable processor affinity to run on more than 1 core (which is what FSO does by default)
However, mileage may vary and it's not a supported operation if you choose to under take it.
As already mentioned, we would need to have a lot more HLOMs (High-Lover Order Managers) in place that are thread safe and thread aware to co-ordinate before we could implement multi-threading. Which means re-writing a lot of stuff into being thread safe first so that it can even be managed in the first place.
That being said, there are still a few places where the engine can gain some enhancement without resorting to a multi-threading re-write project. While there may come a day when that becomes the final obstacle, we'll hopefully have the code base in a condition where the transition will take less effort than it would right now. Assuming of course that it ever becomes a constraining limitation on the performance of the engine, which at this point is still some what doubtful as there many places that still need improvement. (Collision detection and handling, Asteroid field management, just to name the biggest two).
There is also a significant question as to HOW we could approach going about adding multi-threading. For example, we can't really leverage OpenMP (which is related to Multi-Processing, not necessarily Multi-Threading but could still be something to cite as being able to give gains to the FSO Engine) because that excludes anybody that uses MSVC Express edition and that doesn't exactly help us any. Just as an example of being cautious about how to go about doing things.