Rather than storing a comparator, the more likely choice is probably something like the hashmap raw_entry API, where you provide the hash and an equality check callback, and insertion takes a hashing function.
For BTreeMap IIUC you'd just need impl Fn(&Key) -> Ordering for lookup and Key, Value, impl Fn(&Key, &Key) -> Ordering for insertion.
A stored comparator object is certainly more convenient, but providing one only when it's needed is more general and Rust has already biased for intrinsic ordering (e.g. cmp::Reverse<T>) rather than comparators.