It is not wrong to have code just for tests. This is actually normal, just like production code contains features that are made just for debugging and production monitoring. There is no clear reason this should be disallowed. Code should support all aspects of the lifecyle of the application. Testing is just another part of the lifecycle.
In that sense your approach using interfaces is correct. If you make the rest of the production application also use the interface (and not the concrete class although there is only one) it is architecturally sound.
I've kind of gone against what interface is (describes what an implementer can do, not what it is)
I did not get your point here because the interface does describe what the object can do. There being only one concrete (production) implementation does not destroy this property.
If you think about it, every class has an "interface" in a looser sense of the word: the public signature of all methods exposes an interface which the class supports to the outside. Whether a .NET interface is implemented or not is just a detail. The class still makes the same promises to the outside.