In theory it shouldn't be a problem. HTTP is supposed to be stateless, and some users will inevitably change their IP pretty frequently anyway when hopping between mobile and Wi-Fi networks so it's not like that sort of behavior is unheard of.
In practice though, I have no idea. It's entirely possible there's some subset of websites making bizarre, incorrect assumptions about the relationship between users and individual IP addresses, and that dividing HTTP and HTTPS requests between different IPs could break them.
If it turns out to be a problem, as a mitigation you could set it so that once you make a plaintext HTTP request to a specific domain without the response immediately redirecting to HTTPS, any future requests to that domain happen over the proxied connection for some period of time, regardless of whether those requests are HTTPS or not. That way full HTTPS sites would benefit from not needing to go through the proxy, whereas mixed content sites would not.
In practice though, I have no idea. It's entirely possible there's some subset of websites making bizarre, incorrect assumptions about the relationship between users and individual IP addresses, and that dividing HTTP and HTTPS requests between different IPs could break them.
If it turns out to be a problem, as a mitigation you could set it so that once you make a plaintext HTTP request to a specific domain without the response immediately redirecting to HTTPS, any future requests to that domain happen over the proxied connection for some period of time, regardless of whether those requests are HTTPS or not. That way full HTTPS sites would benefit from not needing to go through the proxy, whereas mixed content sites would not.