I think Larsenal has given the best answer so far, but I'd like to expand on it to give a concrete example from working enterprise-level code (not in C#, but another ECMAScript-based language). In my code, I can treat Classes that are fundamentally different things as if they were the same from the viewpoint of the client code.
In my application, I have an IPaging Interface that defines functions like nextPage(), previousPage(), etc. This Interface is implemented by View Classes, but also by Controller Classes. What this allows me to do is bootstrap the application with a View that directly implements IPaging that gets passed to the Application's currentPaging variable. This View is already up and running while the Controllers are loaded with the data they need to proceed. This gets something interactive in front of users right away.
Once they're past that View, the Application's currentPaging variable is then given an instance of a Controller that implements IPaging. That Controller might then implement IPaging by calling those same functions on an IPaging View (that might again have IPaging Views inside it that allow nested, hierarchical navigation), or it might implement IPaging a different way, by swapping out pages of data to a View that has nothing to do with IPaging. The choices are literally limitless, and I can use the same Application framework with Views or Controllers that are customized to be slightly or very different based on the requirements we get. And our clients, like most clients, are nuts--so we have to be as flexible as possible.
I have never regretted using an Interface when perhaps there are only one or two implementations, but I have dearly regretted not using an Interface when I need an implementation that doesn't inherit from the same base Class and I didn't use an Interface. And once you have references to a specific Class spread all through your codebase and referenced from multiple projects, it's tough to put the genie back into the bottle.
One advantage of Interfaces that I get in the language I use (that I suspect you could also have in C#) is that I have the choice to load in implementations of the Interfaces I use at runtime from an external source. The loading Application doesn't need to compile in the Class definitions of the loaded implementations--it only needs the definition of the Interface to be able to cast to that Interface. Interfaces, by definition, have virtually no code in them.