> ...import actions are not supported for AAD User...
I hope you don't understand the question, and there's still an answer out there somewhere. People don't want to import to AAD user, they want to import in any other table that has a lookup column to AAD user. Seeing as how no one can get it to work, you're probably right.
All the system should need from the virtual table is to read data and autocomplete the ID, saving it behind the scenes in the dataverse table's lookup column. We can see that it already can do that in the normal one-record-at-a-time interface, but during an import, it seems to always bomb out.
It sounds like the conclusion is that no import actions are supported for any dataverse table with a lookup field related to AAD User? Why would MS even bother creating AAD User if nobody can ever get started with it, unless their org was born yesterday and has no data to import? It sounds like a big waste of time to try and use it only to have to start over and create our own "AAD User except that it works" mirror table, rebuilding it with the exact same data, ourselves? That would be a shame.