All implementations of EAV, even if you have the kind of "metadata table" you are describing, result in the Inner Platform Effect:
The inner-platform effect is the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using.
It's up to you to write code in your client layer to implement enforcement of basic things like data types and simple constraints.
For example, you are right that you can separate the varchar, date, and integer attributes into three tables. Alternatively, you could create a single attribute table with three columns of varchar, date, and integer, and store your value in the column for the correct data type of a given attribute, while the other two would be NULL.
But either way, how does your client application know which table or which column to use? You would have to write client code to consult your metadata table per field, and build the SQL queries through conditional logic. Every time. No matter how simple the query would be in a normal database, it now becomes a major effort, and you will end up writing screens and screens of query-template-builder code to try to make it easier.
Then you may have some attributes that are mandatory for a given model. In normal table design you'd just designate a column as NOT NULL. But here, you'll have to add more columns to your metadata table to define an attribute as mandatory.
Then you might also consider whether each attribute can have a DEFAULT. Or character sets and collation. Or different types like DECIMAL.
Think about how you would model a UNIQUE constraint in an EAV table. Or a FOREIGN KEY constraint.
Eventually you will implement a database, within a database. That's the Inner-Platform Effect.
It can be done, but it's a lot of work, and you will be responsible for the inevitable bugs. Full relational databases take dozens if not hundreds of engineer-years to implement, and they still have bugs.
