For an event to be handled by an event map they must reach it. If you dispatch an event from a view it will reach the event map if it bubbles, but bubbling only works in the display list. That means that whatever you do an event dispatched from a non-view will not reach the event map.
In your example you dispatch a NavigationEvent from the manager and because of how the event system in Flash works that event can only be heard by listeners listening explicitly on that manager. To get around the problem and dispatch events so that they reach the event map you need to dispatch the event from something else.
By default an event map listens for events on Application.application. This is a reference to the top level view of your application, and also the top level of your view hierarchy, meaning that all events dispatched from views (and that bubble) will eventually reach this view*. If you dispatch an event from that view (and you can since it's a global variable available anywhere) it will be heard by the event map.
Before you start littering your code with code like Application.application.dispatchEvent(...) there is another way to do this that doesn't tie your code to a global variable (because we don't want to end up in the same mess as we would with Cairngorm, do we?).
In an event map you can get a reference to the event dispatcher the map uses with the variable scope.dispatcher. This can be injected into non-view objects that need to communicate with the event map, for example managers and presentation models. The easiest way to do this is to inject it when you create the manager or presentation model. I usually do this in an event handler block that runs early:
<EventHandlers type="{FlexEvent.INITIALIZE}">
<ObjectBuilder generator="{MyManager}" constructorArguments="{[scope.dispatcher]}"/>
<ObjectBuilder generator="{MyOtherManager}">
<Properties dispatcher="{scope.dispatcher}"/>
</ObjectBuilder>
</EventHandlers>
In the example above I included two different ways of injecting the dispatcher, either as a constructor argument or by setting a property just after the object has been created. The scope.dispatcher variable has the type IEventDispatcher.
Some may argue that scope.dispatcher is just as evil as a global variable because it's just a reference to Application.application and hiding it behind a local variables changes nothing. This is not true. By using the variable provided by the event map we know we get a reference to the dispatcher that the map uses, but that is all we know. Our code doesn't know that it's a reference to Application.application. Changing what the variable refers to doesn't affect our code -- meaning also that our code can work just as well with a local event map (and there it's most definitely not a reference to a global variable behind scope.dispatcher in a local event map).
This question is another example of where Mate uses Flex but Cairngorm invents another global variable to solve a perceived problem.
Oh, well. This was a long answer to a simple question... the short version is: you need to make sure the manager has a reference to the dispatcher that the event map uses. The easiest way to do this is to get scope.dispatcher into the manager, and dispatch your events on that.
* There are exceptions, for example views that are in popups, but Mate handles this by also listening to events that reach the system manager, if I'm not mistaken.
