1.) It's always a text-based interface. The ORM merely hides the fact. Type safety is weak, as is with JSON, but both aren't un-typed.
2) Yes, they are, and there are a lot of good use cases for relational databases. But if you have a number of services that share nothing (especially not the database), what is the foreign key good for?
3) You can do any style with any database. Overly aggressive normalization in read-heavy environments can be bad, as is de-normalization in write-heavy environments. Choose the tool for the job..
4) Why all over the code? Can't you make it easy to find the model classes? Doesn't seem so hard. Also, is this so different from, say, EF code first? And anyway, doesn't every SQL database in fact, have multiple schemas (the one in the db, the one in the scripts, the one in the ORM and the one in the code?) Is that really so different?