A small number of separate keyspaces are fine, but using a large number of keyspaces will cause performance issues. The problem is not so much the keyspace overhead, but the large number of tables duplicated in each keyspace. Cassandra has per table overhead such as reserving 1 MB of heap. Good advice is to not exceed a few hundred tables.
How will thousands of tables in Cassandra perform? There are open bug reports that indicate having a large number of tables in the thousands can cause high CPU utilization CASSANDRA-10588 and longer startup times CASSANDRA-794.
Randy Fraden at BlackRock gave an excellent presentation at the 2015 Cassandra Summit on Multi-Tenancy in Cassandra at BlackRock. As noted above, the usual recommendation for multi-tenancy is to put the tenant_id in the partition key. BlackRock then used custom IAuthenticator and IAuthorizer modules to enforce tenant security at the level of a partition.
For those situations which require the same tables in multiple keyspaces, there is a feature request to allow for template tables CASSANDRA-7662 which would add a little syntactic sugar to ease the task of creating similar tables.