As fgrieu already pointed out, using a OWF in the way you describe would make the key schedule not efficiently invertible (or even not invertible at all), meaning you would need more memory/chip space to store the user-input key in order to efficiently encrypt more than one block.
In terms of other implications, if the key-state update function $e_n(\cdot)$ is non-surjective then the later round keys will have less entropy than the user-input key, and hence may be guessed with less effort than with the current AES key schedule. This could make the last rounds easier to peel off.
However, if $e_n(\cdot)$ is such that every output bit is a high degree non-linear function of every input bit, then any such loss of entropy would likely be very difficult to exploit, and also would likely make related key and biclique attacks more difficult.
You should also be aware that OWFs can be used in the key schedule in a different way than you describe -- i.e. as round key extractors instead of as key-state update functions. So you might have a permutation (perhaps even a linear one) to update the key-state between each round, but then derive each round key from the key-state using a OWF. As a concrete (but slow) example, your key-state update function might be to add 1 (or some other constant) to the user-input key between each round, and then extract the current round key from that by hashing the key-state with a cryptographically secure hash function like SHA-256. As a much faster example, Serpent uses a linear key-state update function, and non-linear round-key extractors (though in that case they are non-linear permutations using the Serpent s-boxes instead of OWFs).
