As is usually the case, there are a number of ways to handle it, all depend on your specific situation.
If you had 50 modules and a deep link might take you to any of them, you would want your deep link logic to determine at the time you're attempting to navigate which module to load or if it's already there. You wouldn't want to load 50 modules if the user might only visit one.
If you only have one or two modules and they're small you might want to simply load them before handling any navigation. In fact, you don't even have to load the modules at all, you could simply instantiate them inside the shell if there is no other overarching reason to load them. In fact that could give you the shortest initial load time.
If you look at the old code for Sea of Arrows1
(before it was pulled out into the framework that also drives PureMVC TV - a narrated slideshow), you will see how I handled it. I had only a few modules and their plumbing architecture is fixed, so I compile them directly into the app and just instantiate them. This gives me the extra level of code separation afforded by a modular solution, but loading them was a pointless step since they're all required. I can always break one of them out of the codebase, compile it separately and load it if need be, so there's no harm in going modular but not dynamically loading the modules themselves.
I used a the StateMachine utility to carve up my runtime into discrete states - plumbing, configuring, assembling, navigating.2
First, I instantiate and plumb the modules, then read and distribute configuration to the modules, then assemble the view components, and finally handle navigation. Also, note in the link to the slide below, I am doing swfaddress-style navigation directly to a specific slide. But I'm using Flex's BrowserManager instead of swfaddress.1
Sea of Arrows codebase: http://seaofarrows.com/srcview 2
A slide showing the FSM for the Sea of Arrows player: http://puremvc.tv/#P004/T435