Initialize them anywhere that a reasonable programmer could find them easily enough. The more obscure you make using them in your deepest dankest code, the more attention you have to give to ensuring that there is a clean interface to that obscurity.
Remember, once created, other portions of your code may need access to the handles. If you are stashing them in the handles structure, be sure to guidata() the new handles structure into place.
GUIDE promotes the idea of creating all you figures and UI ahead of time and leaving it existing, but possibly making it invisible. That is one approach. I personally tend to prefer to create and destroy my UI components at need.
One thing I found through experience is that any time I had code that acted differently depending on whether a particular UI component existed or not (e.g., ishandle()), that chances were good that sooner or later the meaning of having that component exist would drift, leading to situations where testing the handle would no longer be correct.
For example, if I test whether guidata.statsfigure is a handle in order to decide whether a statistical analysis is currently underway, then eventually that statsfigure will need to exist for another reason (even as simple as the user asked to leave it up while running the next step), and the state implied by the existence or not of the object would get out of whack. Better, I found, to have explicit state variables rather than relying on a presentation object's existence to encode state.
