As SpikeX said - you can simply assign objects of a subclass to variables of the parent class. But obviously, there's a problem with that because you can't directly access the members that the subclass defined. So, if for example your Button has AButtonMethod() and RecalibrateButton has ARecalibrateButtonMethod(), the only way to access the latter is by doing a typecast:
That's not exactly convenient, but it works. However, if RecalibrateButton overrides a method, e.g. if it has it's own definition of AButtonMethod(), the oo-runtime will automatically execute the version of RecalibrateButton when you call it. So, you might consider not creating ARecalibrateButtonMethod() when you could also override AButtonMethod(). But if that doesn't work in your specific design, you'll have to fallback to the typecast approach. One thing that I do frequently in such cases is adding a property that handles this for me (just a matter of convenience and cosmectics):
public RecalibrateButton RecalibrateButton {
get { return (RecalibrateButton) button; }
}
That way, you can conveniently access "button" as if it was a RecalibrateButton.
No. That's the point of deriving from classes, the derived class inherits everything from its parent classes (everything that's public and protected, anyway). What you can do, though, is something like this, inside the constructor or elsewhere:
button = new RecalibrateButton();
since the "RecalibrateButton" is of type "Button", you can instantiate it, and the "button" becomes a "RecalibrateButton", even though it was defined as a "Button". So you don't need to redefine "button" at all (in fact, don't!), instead, just create an instance of the child class inside of it.
Your code is legal C#, and in my game I can get it to work if the class is not a MonoBehaviour. (Although I have not tested it with SerializeField). This makes it look like the reflection used by MonoBehviour to build inspectors, etc., might be the reason it is flagged.
The other solutions by other posters will work and are simple enough to implement, but you might also consider a refactoring which involves moving the field to a non-MonoBehaviour class. (This of course depends on the rest of your design; it might also be a terrible idea).