I have a widget that displays a filesystem hierarchy for convenient browsing (basically a tree control and some associated toolbar buttons, such as "refresh"). Each of these widgets has a set of base directories for it to display (recursively). Assume that the user may instantiate as many of these widgets as they find convenient. Note that these widgets don't correspond to any business data -- they're independent of the model.
Where should the (per-widget) set of base directories live in good MVC design?
When the refresh button is pushed, an event is trapped by the controller, and the event contains the corresponding filesystem-browser widget. The controller determines the base directories for that particular widget (somehow), walks that directory path, and passes the widget some data to render.
Two places I can think to store the base directories:

The easy solution: make the base directories an instance variable on the widget and have the controller manipulate it to retain state for that widget. There's a conceptual issue with this, though: since the widget never looks at that instance variable, you're just projecting one of the responsibilities of the controller onto the widget.
The more (technically, maybe conceptually) complex solution: Keep a {widget: base_directory_set} mapping in the controller with weak key references.

The second way allows for easy expansion of controller responsibilities later on, as putting things in the controller tends to do -- for example, if I decided I later wanted to determine the set of all the base directories for all those widgets.
There may be some piece of MVC knowledge I'm missing that solves this kind of problem well.
The anomaly (from the MVC viewpoint) that makes this design difficult to make MVC-conformant is that you want to display information that, by your conceptualization, "does not live in a model".  There is no such thing as "information that does not live in a model" in MVC: its conceptual root is "the models hold all the information, the views just do presentation tasks, the controllers mediate user interaction".
It's quite possible that the information you're displaying doesn't "correspond to any business data", but (in an MVC worldview) this does not mean that info is "independent of the model", because there is no such thing -- it just means you need another model class (beyond whatever you're using to hold "business data"), to hold this "non-business" data!-)
So when the user "instantiates a widget" (creates a directory-display view, presumably by some user action on some master/coordinating view, possibly on another existing widget if "cloning" is one of the ways to instantiate a widget), the controller's responsible for creating both a widget object and an instance of the "directory-display model class", and establish connection between them (normally by setting on the widget a reference to the relevant model instance), as well as telling the model to do its initial loading of information.  When the user action on the widget implies an action on the model, the controller retrieves from the widget involved in the event the reference to the model instance, and sends that instance the appropriate request(s) (it's the model's business to let the view[s] interested in it know about changes to information -- typically by some observer pattern; it's definitely not the controller's business to feed the view with information -- that's really a very different approach from MVC!).
Is the architectural investment required by MVC worth it, in your case, compared to a rougher approach where the information flows are less pristine and the model that should be there just doesn't exist?  I'm a pragmatist and I definitely don't worship at the altar of MVC, but I think in this case the (relatively small) investment in sound, clear architecture may indeed repay itself in abundance.  It's a question of envisioning the likely directions of change -- for example, what functionality that you don't need right now (but may well enter the picture soon afterwards) will be trivial to add if you go the proper MVC route, and would be a nightmare of ad-hoc kludges otherwise (or require a somewhat painful refactoring of the whole architecture)?  All sort of likely things, from wanting to display the same directory information in different widgets to having a smarter "directory-information watching" model that can automatically refresh itself when needed (and supply the new info directly to interested views via the usual observer pattern, with no involvement by the controller), are natural and trivially easy with MVC (hey, that's the whole point of MVC, after all, so this is hardly surprising!-), kludgy and fragile with an ad-hoc corner-cutting architecture -- small investment, large potential returns, go for it!
You may notice from the tone of the previous paragraph that I don't worship at the "extreme programming" altar either -- as a pragmatist, I will do a little "design up front" (especially in terms of putting in place a clean, flexible, extensible architecture, from the start, even if it's not indispensable right now) -- exactly because, in my experience, a little forethought and very modest investment, especially on the architectural front, pays back for itself many times over during a project's life (in such varied currencies as scalability, flexibility, extensibility, maintainability, security, and so forth, though not all of them will apply to every project -- e.g., in your case, security and scalability are not really a concern... but the other aspects will likely be!-).
Just for generality, let me point out that this pragmatic attitude of mine does not justify excessive energy and time spent on picking an architecture (by definition of the word "excessive";-) -- being familiar with a few fundamental architectural patterns (and MVC is surely one of those) often reduces the initial investment in terms of time and effort -- once you recognize that such a classic architecture will serve you well, as in this case, it's really easy to see how to embody it (e.g., reject the idea of an "MVC without a M"!-), and it doesn't really take much more code compared to the kludgiest, ad-hoccest shortcuts!-)
wxPython: How should I organize per-widget data in the controller?