Technically, it and the rest of the engine is unitless and you can consider it to be whatever you want so long as you're consistent. But most likely, you would consider it to be seconds when constructing a regular simulation.
I should also mention that the Space.Update(dt) method performs internal time stepping. This means that the engine accumulates the time you pass in each frame and simulates a number of individual time steps to get as close as possible to the accumulated time. The time step duration is defined by the Space.TimeStepSettings.TimeStepDuration, which defaults to 1/60f.
Internal time stepping is useful when the game doesn't have a fixed time step, but you want a constant simulation rate. Note that since a varying number of time steps can occur each frame and there might be some time left over, the motion may not be perfectly smooth. To address this you can use interpolated states (more information here: http://bepuphysics.codeplex.com/wikipag ... umentation).
Space.Update() without the dt parameter performs a single time step.
The simplest approach is to have the Game's target update rate to be 30 hertz (I believe that's the default on the phone), set the Game's IsFixedTimeStep to true if needed, set the Space.TimeStepSettings.TimeStepDuration to 1/30f, and call Space.Update() once every Game update.
Using 1/30f time step duration will span more time with each Space.Update(), so it will do less work and be less accurate. You could also set the time step duration to 1/60f (the default) and call Space.Update() twice in the Game's update, spanning the same 1/30 time but with greater expense and accuracy.
You could also turn off the game's IsFixedTimeStep and pass the elapsed time to the Space.Update(dt) method and let it take however many steps of TimeStepDuration as necessary.