Just in case you're interested, here's some of the design-time issues I've faced and solved. I've tried to comment on them extensively in the code so this control is really a good example for design-time solutions, in case you ever find yourself requiring it.

Designer serialization:
Once you add panels to the control at design-time, the windows forms designer has to 'serialize' these panels into the Designer file, in the InitializeComponent method. The most important part here is to use the DesignerSerializationVisibility attribute on the Panels property. This property returns the ControlCollection of the panel that contains all OptionsPanels (in other words, it just returns all OptionsPanels), so adding to this property actually adds the panels to the Control collection of the container panel. By setting the DesignerSerializationVisibility attribute to Content then, the designer knows to serialize the contents of this container panel, in this case the OptionsPanels! If you don't set this attribute, the panels would not be serialized and would be lost once you run the application.

Another issue is the nodes in the TreeView. They are instances of the OptionsNode class, which inherits TreeNode. They are serialized because the designer automatically looks for a method 'ShouldSerializeNode', in which I return True. Then, their Nodes property (the child nodes, if you will) should also be serialized, so the OptionsNode class has a method ShouldSerializeNodes, which also returns True. These methods aren't used anywhere in my code, the designer looks for them (by name) and simply assumes 'False' if they don't exist.

A more pressing issue was the way these OptionsNodes were serialized. By default, the designer creates new TreeNode objects and tries to cast them to OptionsNode. That won't work, that's a cast from a base type to a more derived type, impossible! To get around this, I had to implement a custom TypeConverter for the OptionsNode class (OptionsNodeConverter). This provides an InstanceDescriptor object (which basically describes the creation of an instance in the Designer file) that calls the correct constructor on the OptionsNodes.

Property grid functionality:
Another issue was the ParentNode property. I had the idea to let this property show a dropdown in the property grid, containing all nodes in the TreeView, from which a user can select the right parent node. To get this behavior, I had to implement a custom UITypeEditor for the ParentNode property (OptionsNodeEditor). I tell the property grid to display a dropdown with a ListBox, to which all nodes are added.

The creation of the OptionsPanels in the first place also required a custom UITypeEditor, this time a custom CollectionEditor. By default, the editor for the Panels property creates Control instances (because the collection, Panels, is of type ControlCollection). That won't do, we need OptionsPanels, and I use the OptionsPanelCollectionEditor to get it to do just that. Furthermore, instead of returning a new instance of the OptionsPanel class, I use the DesignerHost to create an OptionsPanel component. This allows the panel to be selectable and editable during design-time (otherwise it would be a static control, like controls on a UserControl).

Control Designers:
Both the OptionsView and OptionsPanel feature custom ControlDesigners. These control the design-time behavior of the controls. The most important feature is the ability to select nodes in the TreeView. This is done by overriding the GetHitTest method and returning True when the mouse is over the TreeView.
Furthermore, the designers add the ActionList / Smart Tag window features.

Finally, I draw a neat little border around the OptionsPanels (code 'stolen' from the PanelDesigner that draws the border around a Panel control) as well as their name in the bottom-right corner to identify them. Obviously, these drawings only appear during design-time.