You basically want option (c). Option (d) might work, but you would be bending the paradigm a bit, IMO. Certainly do not use dedicated column families or keyspaces per tennant. That never works. The list history will show that with a few google searches and we've seen it fail badly with several clients.
Overall, option (c) would be difficult to do in CQL without some very well thought out abstractions and/or a deep hack on the Java driver (not in-ellegant or impossible, just lots of moving parts to get your head around if you are new to such). That said, depending on the size of your project and skill of your team, this direction might be worth considering.
The commercial version of Usergrid has "tens of thousands" of active tennants on a single cluster (same code base at the service layer as the open source version). It uses Hector's built in virtual keyspaces: https://github.com/hector-client/hector/wiki/Virtual-Keyspaces
(NOTE: though Hector is sunsetting/in patch maintenance, the approach is certainly legitimate - but I'd recommend you *not* start a new project on Hector).
In short, Usergrid is the only project I know of that has a well-proven tenant model that functions at scale, though I'm sure there are others around, just not open sourced or actually running large deployments.
Astyanax can do this as well albeit with a little more work required:
Happy to clarify any of the above.