The lifecycle of the db tables on a DO are entirely in your control. There is no 'hole'.
In my case, I create a DO for each user, which includes social auth (behind a captcha as well). I manage a registry of users in a central DB, not the DO. The registry contains stub ID for each DO I manage. This part isn't necessary, but it's helpful. When a new DO is created, I run the initial migrations needed to set it up. The gate to avoid abuse in my case is that random sessions / bots can't create users so easily with a single URL. They have to create an account.
When a user makes a request against the DO, thier session cookie is part of how I map them back to their DO for subsequent requests.
There's really nothing that says a DO is tightly coupled to DB tables just because you instantiated the stub. There are many ways you can ensure the tables exist before querying them.