Well, the documentation contains an example of using the KnownTypeAttribute. Note that it allows multiple attributes on the same class, so you can identify more than one polymorphic child type.
This is quite limited functionality since it only allows you to specify types known at design-time, so it doesn't really fit into the extensibility and maintainability mindset that normally makes us use polymorphism in the first place.
AFAIR, this limitation exists mainly because of constraints in WSDL/XSD, to which WCF contracts are often translated. We must always recall that only messages travel across the wire - not objects. The client at the other end may not be a .NET application at all, so for the sake of interoperability, these are the constraints we have to accept.
I usually find that a more static redesign of the service interface is often a better solution. You could also consider exposing the return type as System.Object, which will translate to xs:any, but obviously you will lose type safety along the way.
WCF has an advanced option that allows you to share types between server and client, so this may also be a solution for you. However, you lose interoperability and a host of other goodness if you do this, so consider this option carefully before you choose it.