I don't believe this is the case (IIUC; someone may be able to correct me). The type of the struct is Curve32(Curve<f32>) not Curve32. So, you wouldn't be reducing the type-resolution cost any more than just using pub type Curve32 = Curve<f32>.
The way I understand it, types like Curve<f32> are (hypothetically) not really a problem, because they have only one solution, but in practice functions can be codegen'd multiple times due to compiler implementation details. The unstable option -Zshare-generics should address many compile speed issues related to monomorphization.
On the other hand, it becomes a problem when you have many types: Curve<f32>, Curve<f64>, Curve<N32>, Curve<N64>, Curve<R32>, Curve<R64>, ... because codegen has to do more work to monomorphize and deduplicate implementations generated for each function for every type. And this issue can be addressed, somewhat, with non-generic inner functions or polymorphization.
But anyway, do you know for certain that monomorphization is the problem? Have you benchmarked the compiler building your crate or workspace with cargo --timings or -Zself-profile?