Yes and no. It won't work using AD based names with a domain suffix but I did get it working using native Okta accounts without domain using OpenLDAP.
The reason AD-based logins won't work is because VMware truncates the domain suffix during the initial authentication step - in other words, it uses the domain suffix to determine the identity source to use, then discards it. So for example, if you enter user1@domain.com, VMware will search the domain.com identity source for a corresponding user. If it finds it, it will send the auth request to that identity source for validation. If the name is validated, VMware will receive the response back with the name (ie. user1) WITHOUT the domain suffix attached .. so at that point, VMware will not be able to match the response (user1) with a user in that identity source. I don't know if VMware does this on purpose, but its certainly something they could fix programmatically.
So, to workaround this, you can use a native Okta user which does not have a domain suffix. That way when you add the user into VMware, it will show up as "domain.okta.com/user1" and VMware will have no domain suffix to truncate. MFA will still work though - Okta does provide a KB for accommodating that (you simply append the MFA challenge to the password when you login to vCenter - obviously you need to have the MFA challenge prior to the initial login, so you have to use something like Okta Verify). Unfortunately, this doesn't allow you to use your internal admin accounts from active directory, for example.
I wrote up an explanation of this and sent it to Okta so maybe they will publish an official KB or something, but it is odd that VMware doesn't have better support for MFA or other external IdPs.