I'm not sure if interfaces are going to help you a lot here. My understanding is that you are breaking a page down into set of "composite" user controls that contain other controls, and you want to decide whether to use properties for setting values.
I guess this really depends on how the user controls are designed and whether they are being dynamically added to a page etc (one possible scenario). I have a personal preference for specifying stuff in a constructor or using a factory method to create controls. I assume responsibility at creation for making sure that everything is set. My experience with properties is that I'll sometimes forget to set something and not realize my mistake. Your point about setting properties or using a sub, and everything being populated doesn't make a lot of sense to me. If you have some sort of dependency and need something else to be loaded then this could happen irrespective of whether it's a property or sub.
I would refer to any book on VB.NET/C#/OOP to see the syntax for interfaces. Interfaces basically describe a contract for a class. If you have class A and B and both implement an interface called ITime then both will provide all of the methods defined on ITime. They can still add their own methods but they must at minimum include an implementation of ITime's methods (eg. we might have GetDate(), GetCurrentTime() as methods on ITime). An interface doesn't tell class A or B how those methods should work - just their name, parameters and return type. Lookup inheritance in an OOP book for more information on how interfaces inheritance is different from implementation inheritance.