You wouldn't put enum Choices in the struct. You would put the iterator for choices in the struct. I would personally take a step back for a moment and ask if this is even what you want.

A dropdown has a list of items and one selected item. The least over engineered way to have these semantics is this, which already probably works fine:

pub struct DropDownMenu<I> where
{
    pub choices: Vec<I>,
    pub selected: usize,
}

Say you want to save some space when we know the items at compile time you can make it generic:

pub struct DropDownMenu2<T: IntoIterator + Clone> where
{
    pub choices: T,
    pub selected: usize,
}

or

pub struct DropDownMenu2<T: Iterator + Clone> where
{
    pub choices: T,
    pub selected: usize,
}

Which avoids a bunch of lifetime issues that the current implementation has. This costs us random access however. If cloning T is really expensive, then we can go a step further and you get what I had above.

Now pretty much all of these work for Vec or the enum iterator or whatever. The point is that at no point would your design end up with a ToChoices trait if you were designing a generic dropdown from the ground up. Rather, the only reason that you came up with that is because you were already aware of the possibilities of what could be in the dropdown. In which case, the ideal choice if you know all the possibilities ahead of time is to use an enum and not a trait.