If you want to make a subclass that exists just to claim those stronger guarantees, fine, but asking existing consumers of this API to give up performance and the invariant that the length of the list matches the number given, is something I'm very strongly against.
It seems that the thing that is requesting the extra functionality should pay for it via subclassing and either providing another method, or incurring extra laws for the superclass method. I have a general preference for making the operation with the extra laws have another name and be an inhabitant of the subclass, though, because then users aren't hoist on the horns of the dilemma of which semantics they want their fromListN to have. They don't have to choose between speed and being able to implement the subclass.
Mind you IsList is a terrible class. I _really_ wish toList could be allowed to fail, or could be moved to a separate class, then you could use it in syntax trees where one of the cases was list like and what not. We can use fromString in all sorts of places where fromList cannot be used because of this self-correcting embedding/projection-like constraint.
-Edward