You don't have to register the skin in web.config, only the custom (skinable) control.
The skin properties and styles for a (custom / skinable) control are static within the skin, so you can't switch them at runtime. Many of the attributes are setable on the controls themselves at runtime (like forecolor, backcolor etc.), but those that need skinability there are basically two options that I can think of right now.
You can create a Skinable control for each flavor you want to implement, which would mean you have x number of skinable control which you must all register in web.config. At runtime, you could then simply set the control.CustomStyle to any of the available custom styles you have prepared, and as they would all be inheriting from the same base control, they would work the same as the base control but render in different flavor.
Second option is very similar, except you would build only one skinable control, but modify the skin (the xslt, css ...) to handle more than one flavor and handle it correctly, meaning that when flavor-a is detected you would render the control with the correct css for that flavor etc. The same approach would work for switching flavors runtime, meaning you simply assign a different value to Control.CustomStyle. For this method, you would have to make sure the XSLT would match all the flavors based on the different CustomStyle values you want to offer.
The difference between these two flavoring methods is not that much, as the single-control solution would need to have all the matching in one xslt what would be matched by individual controls in the multi-control solution.
Hope this helps,