Very nearly correct. An interface is a defined way for one piece of code to interact with another. Your code is already using interfaces informally - every module you use is accessed through an interface: the stuff it makes public.

The trick here is to define the interfaces that you need and to write tests against those interfaces. Defining interfaces allows you to partition the code off so that things can be worked on independently on either side of the partition without. And yes, the benefit is exactly as you describe.

The initial hard work is identifying where formal interfaces are required and implementing them. The implementation should be fairly light weight and should be a simple matter of writing a new module for each interface that receives calls from the old "client" code and passes those calls through to the old "server" code. Here "client" is simply the calling code and "server" is the called code. The intent is to emphasise the point that there are two sides to the interface. The interface itself is just a line drawn in the sand. The temporary module I suggest is just a shim that allows implementation of the interface on your existing code so that tests can be written against it.

Note that this fits very nicely with the "Strangler Application" technique mentioned in one of the other replies you received.