Currently its not possible to configure the Cassandra session in any significant way.
I'm happy to offer up a PR for this issue if we can agree on acceptable approach that's likely to be merged.

Exposition

CassandraDataStore construction accepts CassandraOperations and CassandraOptions instance.

CassandraOperations is the "DAO" and holds the Cassanda session and actually provides the relevant methods.

CassandraOperations initilizeds the session during construction and further uses the private final session field in all the method implementations. So sub-classing this class is not really a viable option to inject session configuration.

SessionPool is a singleton and can't really do much about configuring the Cassandra Cluster.
We do get the options passed into SessionPool.getSession but only thing that is done is getting and caching on contact points.

Alternatives

One option would be try to flesh out the Cassandra options that are passed from command line. This seems challenging because Cluster.Builder has a decent number of configurations some of which require intermediate construction. At a first glance it may be a whole set of SPIs that would need to be introduced and that's a lot of weight to carry around in the project.

Easier and flexible option would be to turn CassandraOperations into an interface which would allow the user to sub-class it. That would place the responsibility of managing the session pool on the client code but that does not seem out of line. I believe swap of CassandraOperations to interface or abstract class and addition of CassandraOperationsImpl would also preserve binary comparability, making it easy to release. I think abstract class makes the most sense here so user can avoid copy/pasting the implementation.