Managing Interfaces

Phew....

20 Interfaces is not ideal.

To answer your question upfront: No, you cannot group or alphabetize your Interfaces.
That being said, you shouldn't have to.
Something I've seen a lot since Interfaces were first released is people creating new Interfaces when they should actually be creating new Interface pages.

Suppose you have a sales pipeline that you're managing and within that pipeline you have three types of potential deals.
Well, you naturally want to create a new Interface for each type of deal. Instead of creating new Interfaces, you should have a centralized "Sales Dashboard" Interface that has Interface pages that allow you to isolate each type of deal record type.

Not only does this eliminate a ton of Interfaces, but it prevents your users from having to jump between Interfaces in order to work with the same data.

I am, of course, assuming that you're not leveraging Interface pages. If you are using them in your Interface design and implementation, then you should probably think a bit more about how you might be able to consolidate and house your Interfaces into more streamlined user experiences.

It is a lot.  We use a lot of contractors and we don't give them access to every interface.  Each department gets 2 interfaces:  one for management/team and one for contractors.  Individual interfaces each have multiple pages.  Each interface has permissions that allow/deny access.  We also have universal interfaces -- for example, a "Help" interface which everyone can access to manage requests for changes.  

I appreciate your thoughts, and as new functionality emerges, we have continued to evolve and streamline our use of the interface functionality. 

Given the number, we'd just like to organize the group so that its easier for those of us who oversee the structure.  Even alpha would be great.

This pain point resonates with me.
While it doesn't do anything to resolve issues with collaboration at scale, know that plenty of us that manage and work with a large number of Interfaces at scale also face similar problems when it comes to Interfaces.
It's something that's been communicated both in public spaces and through private channels to Airtable.
We're kinda just subject to hoping that something is provided to us at some point in the product release roadmap.

This doesn't really help with navigation and the visual layout of the platform, but from a workflow and process perspective, in my organization I keep a visual diagram of our Airtable infrastructure. Specifically, I lean on Lucidchart.
It allows me to know where all my integrations are, the nature of all the synced tables and data sources, which automations live where, where all my webhooks are, where all my API interactions are, and also where all my Interfaces are and which user groups should have access to them in their workflows.

It helps from an admin perspective, but full acknowledgement that it's not the solution to a problem that more and more people and teams will run up against.