First you need to work out the expected row size. The simplest way is to populate the table with some representative data, then analyse the tables (for all indexes) and run the following....
This will give you a reasonable estimate of the table size and the index size for each row. This is a good estimate, not a science.
sum( inds.sizes ) as index_bytes_per_row
decode(data_type, 'DATE' , 7,
'CHAR' , data_length,
'VARCHAR2', decode( sign(data_length)-250, -1, .7*data_length+3, .7*data_length+1),
'NUMBER' , floor(nvl(data_precision,38)/2)+2 ) as sizes
from user_ind_columns i,
where t.TABLE_NAME = i.table_name AND
t.COLUMN_NAME = i.COLUMN_NAME
order by i.table_name, i.column_name
group by inds.table_name, inds.index_name
Then you start considering this in the context of the tablespace in which the table is stored and the tablespace in which the indexes are stored.
AIUI if you only specify tablespace names in the storage parameters when creating the table, it will assume initial, next etc from the tablespace storage parameters. It is possible though to specify mismatched storage parameters for the table/tablespace and become quite wasteful on space.
There also other storage parameters such as pctfree etc which have an affect on allocated size and physical disk storage space - I would recommend you look at them separately.
Please don't email me directly with questions. I've probably just got home from the pub and cannot guarantee the sanity of my answers. In fact, I can't believe I actually made it home.