The total number of kmers is R*(max(0, L-K+1)), where R is the number of reads, L is the read length, and K is the kmer length. If L is variable you could use the average. You can't estimate the number of unique kmers without processing at least part of the file, though.
KmerCountExact stores the kmers to get an exact count of the number of unique kmers, which (can) take a lot of memory. BBNorm is capable of an approximation, using Bloom filters, in an arbitrarily small amount of memory (though less memory means lower accuracy). But BBTools also has an implementation of another technique called LogLog, which can estimate the number of unique kmers using only a tiny, fixed amount of memory (a few kb). As opposed to KmerCountExact and BBNorm, LogLog also runs at about the same speed you can read a file. For example:
loglog.sh in=mruber_60x.fq.gz k=31
Cardinality: 51725986
Time: 6.885 seconds.
That's a 500MB file, so it's limited by gzip decompression speed. Anyway, once you know the approximate number of unique kmers (which is accurate to within a few percent) you can allocate the bloom filters appropriately.
P.S. LogLog by default uses a different random seed on each run, giving slightly different results. On 4 consecutive runs, I got:
51725986, 54242725, 54205118, 56469179
The correct number, from KmerCountExact, is 54913615. BBNorm with 1GB RAM gave 54912534, and with 100MB it gave 54902886.