slimdave,

You said:
> # the optimizer doesn't know that the "id" column is not null.
># placing the object_type second in the list of columns in the composite index reduces the chances of it being used
># The table is so small that the optimizer might choose to use an FTS anyway
># Since all the values of object_type are null, it's more efficient with this data set to FTS anyway

Addressing these issues, here is the SQL:

drop table t;
create table t as select rownum id, all_objects.* from all_objects where rownum < 12000;
update t set object_type = NULL;
alter table t modify (id not null);
create index t_idx1 on t(object_type);
create index t_idx2 on t(object_type,id);

(1) Here the optimizer does know that 'id' is not null.
(2) I placed 'object_type' first in the composite index.
(3) The table has 12,000 rows - not so small that a FTS should be preferred.
(4) Of course - if all the values are one value, a FTS should be preferred. But that was how the original poster specified the situation - a 100% NULL column.

Results:
(a) Using the RBO:
select * from t where object_type is NULL;
SELECT STATEMENT Optimizer=RULE
TABLE ACCESS (FULL) OF T
(b) Using the CBO:
select /*+ CHOOSE */ * from t where object_type is NULL;
SELECT STATEMENT Optimizer=HINT: CHOOSE (Cost=7 Card=11999 Bytes=1067911)
TABLE ACCESS (FULL) OF T (Cost=7 Card=11999 Bytes=1067911)

So - in conclusion - even with a composite index, if one key (1st or 2nd) is 100% NULL, and that is the only value specified in the where clause, then the index is not used. Of course, that is after all what we would expect the optimizer to do -- if a column is 100% NULL, and the only parameter in the where clause references that column, then what use would an indexed lookup possibly be? Answer - of no use at all, of course.