You haven't mentioned your usage of the database. You've mentioned what sort of information you'd be placing in the database, but not how you'd be retrieving the data.

If you will typically not be accessing the bio, then it would make sense to store the TEXT field seperately. If you have the extra disk space, you can always use a materialized view to join the two tables, or to create a sub table without the TEXT field. Whatever you do, make sure that the TEXT field is the last field in the table. (you also typically want to place VARCHARs, or any other variable length fields to be at the end)

As for what's the percentage of reads to writes that makes an index break even, that's another item with no simple answer -- if the reads involve 25% of the records, then the index is most likely never beneficial. You might also have more than one index on a table, so there would be a different point of breaking even on a table with 8 indexes vs. a table with only one index.

It's also possible that the type of tables might be a factor. I have more experience with Oracle than mySQL, but Oracle uses indexes for record level locking in transactions ... I have no idea if innoDB tables do something similar.

So, I'll go back to my past comments about tuning -- no one's situation is the same as someone else's. Different amounts of memory or disk contension may change how things behave. Your best bet is to build a prototype, and try to load it how you think it will be in production. If it doesn't meet your requirements, then spend time tuning it. Every so often, you'll want to see if your load has change, and retune.