Sort HashMap data by value

This could be another way to address the matter without the need of an intermediary vector.

// Count the frequency of each letter
let mut count: HashMap<char, u32> = HashMap::new();
for c in text.to_lowercase().chars() {
    *count.entry(c).or_insert(0) += 1;
}

let top_char = count.iter().max_by(|a, b| a.1.cmp(&b.1)).unwrap();

println!("Most frequent character in text: {}", top_char.0);

use BTreeMap for sorted data

BTreeMap sorts its elements by key by default, therefore exchanging the place of your key and value and putting them into a BTreeMap

let count_b: BTreeMap<&u32,&char> = count.iter().map(|(k,v)| (v,k)).collect();

should give you a sorted map according to character frequency.
Some character of the same frequency shall be lost though. But if you only want the most frequent character, it does not matter.

You can get the result using

println!("Most frequent character in text: {}", count_b.last_key_value().unwrap().1);

Is this idiomatic Rust?

There's nothing particularly unidiomatic, except possibly for the unnecessary full type constraint on count_vec; you could just use

let mut count_vec: Vec<_> = count.iter().collect();

It's not difficult from context to work out what the full type of count_vec is. You could also omit the type constraint for count entirely, but then you'd have to play shenanigans with your integer literals to have the correct value type inferred. That is to say, an explicit annotation is eminently reasonable in this case.

The other borderline change you could make if you feel like it would be to use |a, b| a.1.cmp(b.1).reverse() for the sort closure. The Ordering::reverse method just reverses the result so that less-than becomes greater-than, and vice versa. This makes it slightly more obvious that you meant what you wrote, as opposed to accidentally transposing two letters.

Can I construct the count_vec in a way so that it would consume the HashMaps data and owns it?

Not in any meaningful way. Just because HashMap is using memory doesn't mean that memory is in any way compatible with Vec. You could use count.into_iter() to consume the HashMap and move the elements out (as opposed to iterating over pointers), but since both char and u32 are trivially copyable, this doesn't really gain you anything.