I can't advise as to a best practice, but I can share some observations that I've made.
I worked on a team that built one of the first communities. We began when the newest sharing models hadn't yet been released. As a result, our security model changed several times over before we completed the project. Initially, we'd planned for community users to be able to take ownership of various records but later found that wasn't necessary in order for them to create or edit records they needed access to by using sharing groups and permission sets. The community was built to support outside contractors where all the Contacts were under a single internal company account with a single contact recordtype. They all reported to a limited number of Managers/Owners. We're talking about two thousand or so contractors in total with perhaps 25 Owners.
As I'm sure you're aware, the Community User's Contact Owner or whomever creates them, also needs to have a Role assigned to them. It's the Role of the User's creator that essentially provides the equivalent for a Community User when they're created. That's the best analogy I can make to what seems to happen since I don't know any other way to try and explain how they're created without a having a Role assigned to them. There's some sort of inheritance that's passed from their Owner or Creator's Role that seems to have an effect on what they can access, or so we seemed to observe during our development.
It may have simply been that because the Contact's Owner owned the Accounts they worked on, that's part of what provided them access without explicitly needing it assigned to them at one phase in our development. We eventually went to sharing groups and permission sets, so its possible that my observations could have been made during a transition period in our security model. I wasn't responsible for handling the security part of it so can't say for certain. Things have also definitely changed with the many revisions that have been released related to sharing since that project was completed.
My only concern with your plan would be Community Users that are owned by a User who does not have a Role. We worked around a related issue in our triggers by assigning ownership of records to the Admin when a Community User's Id couldn't be located (we were working from ContactID to Portal UserId). So, will that require your Contacts to be owned by an Admin? Its possible you may find a way to work around that issue in the sandbox. That would be new ground for me that I'd simply be guessing on that I'd want to test thoroughly before trying to implement.
I suspect the easiest way to work around this would be to start by having all Contacts owned by the User who owns all Accounts, then set up sharing groups and permission sets for each Account Team. I'm confident you don't want to hassle with going deeper into your organization unless you only have a few Account Teams and can easily break them into sub-account teams. Whether the sharing groups will impact the issue of Roles will be something you'll need to test. So long as no one takes ownership, I'd expect you'd likely still be safe. Again, only testing will reveal what's going to happen.
As an aside, something to be aware of is that any temporarily disabled/inactive Community Users you might have in your records can wreak havoc with your triggers!
I'll be interested to learn what you discover and hope you'll share your findings.
