well, this doesn't ever really get called: IDBCommand.ExecuteReader(...);
what gets called is your_class_instance.ExecuteReader(...);
and you don't inherit an interface... interfaces are implemented. Now, once it's been implemented, the implementing class can be inherited. But then you're inheriting the class, not the interface.
Interfaces are nothing magical really. There's nothing special that goes on behind the scenes, not notably at any rate. The point of interfaces is to enforce a contract between caller and callee. If I know that a particular class implements ISomething then I can be guaranteed that when I call .DoSomething ... there will be a DoSomething method to be called. I don't care what DoSomething does, or if it even does something. All I know is that that method exists, and has the given signature. It's a way to allow for binding and prevents blind calls.
Example: both OLEDB and SQLClient have an ExecuteReader method... that's because both classes implement the IDBCommand interface. That means I can Dim someDBCallee as IDBCommand ... and then use EITHER SQLClient OR OLEDB classes to create a command object... then I can just call someDBCallee.ExecuteReader ... w/o caring how it does it (Access vs SQL Server) ... all I know is that ExecuteReader will execute the command and return a Reader object....