Fist, have you actually identified an actual problem? Can you show that having a wide table causes some problem for the system in terms of throughput, resource consumption, latency or somesuch? Splitting the table will cause maintenance overhead so you'd better be sure it's justified.
We [sic] trying to think about db index size
The index size is determined by the key column(s). Since the key won't change after the split the index size will be the same. Specifically the index depth will remain the same, and this is where a lot of the overhead comes in. Moreover, I'd imagine both tables will have the same key (UserId?) so twice as much disk will be used to store the index.
Some RDBMS implement BTree indexes where the leaf is the full row. For these, splitting the table will allow more rows to be held in a given amount of RAM, improving performance. You will not see improvement, however, if the DB server is not under memory pressure, or the user table is touched so frequently it is never evicted from memory currently.
and things like caching as the user objects are cached in Redis.
Do you serialized and cache the whole, wide object? Well, doing less work is likely to be faster than doing more work. So splitting is likely to be beneficial. This does not require the split to be performed in the RDBMS, however, only in the Redis cache handling code.
I know in some cases we'd need a couple of db queries to the get the data instead of a single one
Well, maybe. A single query can join many tables & return a single resultset. A stored procedure can return multiple resultsets. A view could be defined which joins the tables and the view can be referenced from the application.
I get the impression an ORM is involved. Your options here may be dictated by it.
One major drawback to splitting is that you now have two objects that absolutely, definitely must be in sync. This will require very careful application code or, more likely, database triggers. This complicates the reasoning about the system. Would it ever be acceptable to have a User without corresponding UserSettings? Under what circumstances can either be removed? How to enforce the 'exactly one' relationship constraint between the two tables? This is achievable but requires planning.