Often we must beware of simple conveniences that are technically breaking a design (sometimes without realizing it).
In this case, you have things that represent something that will be created and the things that are actually created. You've used the same class for both (convenience) even though they are not at all the same things.
So, if you want to continue treating them as the same thing then you will have to take the good with the bad. Either side will necessarily inherit all of the features/properties of the other... in this case, your non-persistent runtime components become persistent.
Alternately, you could decide that keeping both of these objects represented by the same class means that you cannot use default persistence and must choose something else to save them.
Or you could be more pure to your design and use different classes to represent the two different object types. The down side here is some duplication. The benefits are manifold, though: you don't have these bleeding-of-features problems, you can more easily restrict what can/can't be 'templated', you don't accidentally use one thing when you mean another.
It's up to you do decide the trade-offs.
It could even be that a component template does not need a 1:1 correlation to the things it creates. After all, those could be broken down into types and properties on some template entity... though you've really only moved the duplication somewhere else in that case.