OK I just answered this myself... it works perfectly!
Lets say I have a link in a widget page to a remote page, example:
<a href="http://www.mysite.com/somnepage.html">Link</a>
Once I'm on the remote page, all I need to do to get back to the local page is:
<a href="local:///localpage.html">Link back to local</a>
Good job RIM 
Also if you have JavaScript or images that are relatively static and don't change you can embed them in your widget archive and refer to them in your dynamic content you pull from the server.
so you can do something like:
<img src="local:///img/myimg.png" />
or
<script type="text/javascript" src="local:///scripts/foo.js"></script>
In the page you are serving up from your website
It gives you lots of deployment possibilities 
There are a couple of reasons for this..
1) When you launch a widget for the first time it needs to initialize the browser engine. Much like the first time you load Firefox on your desktop. Then when you load subsequent pages it is fast. Our BlackBerry Browser cheats a little in the fact that it has started in the background when the device boots
2) The lack of caching means that any remote resources are going to always be pulled from the network. We are currently working on the caching capability so it is on the way
Once you have your widget open, pulling in an external page that hasn't been cached should be comparable to loading it in the browser.
We also demonstrated some Loading screens at the Developer Conference where we even demonstrated screen transitions between loading states. So there's lots to come
Yeah the non cached pages seem to load about the same, but from there the browser wins with the caching...
I really hope you guys get it soon, I feel the aching is the only real slight problem I see now...
And there ya go teasing me with the tranisions and such... 
haha wish I could have made it out to Dev Con
