Building and storing indexes is not free. If you already understand your access patterns and they involve retrieving large quantities of data to be aggregated the index is less effective than just writing everything down in order and looking where you know the data is to begin with. In a way the storage becomes the index.
Said another way: in analytic workloads the hard part is not finding the data, it is reading the data.
These are orthogonal. An index is used to prevent a full scan of the key space in order to find a record. You have indexes in both row and column oriented databases.
What a column-store database gets you is fewer I/Os on reads since all the data for a column is stored together. This is ideal for some analytic queries on warehouse databases with wide rows.
A database can and will also scan an index and not even touch the table if the index has all the data it requires. I haven't tried it, but the idea of creating an index with just the data necessary for aggregation isn't far fetched.
In a sense storing column values in an index is how row based databases convert to column based. Do that for all the columns and you are logically close. Execution is another matter.