We have to be careful when adding new inference sources to avoid cycles, but the underlying type of a type alias is probably fine to consider.
The actual change is very simple. We collect the list of types from which to infer requirements here: swift/lib/Sema/TypeCheckGeneric.cpp at main · apple/swift · GitHub
You can see for functions and subscripts, we look at parameter and result types. A good starter project for someone would be to split this off into its own function, tidy it up a bit (the nested conditionals are excessive) and add something like this in the right spot,
if (auto *typeAliasDecl = dyn_cast<TypeAliasDecl>(foo))
inferenceSources.push_back(typeAliasDecl->getStructuralType().getPointer());
I don’t know if this merits a proposal or not. (Edit: I’d also be happy with a pitch to phase requirement inference out entirely with a future language mode too 
).