Does indexed column with millions of different values make sense?
For b-tree index , the more distinct values the better. 

Index skip scan doesn't seem to be an efficient access method in your case because the first column in the index has high cardinality. It works opposite to "regular" index usage like index range scan or index unique scan  where you want the first column to be the most discriminating.  It's hard to say if in this particular case full table scan would behave better without trying (FULL or NO_INDEX hints can do the job) . 

No doubt, for the query in  question index on event_id,event_date is much better than on event_date,event_id.  

It's hard to tell without seeing your other queries, but I think you may not necessarily need to have composite indexes.  Each column, event_date and event_id, appear to be have very few duplicates (if any) .  Then having two indexes, one on EVENT_DATE and another on EVENT_ID will work better than having multiple concatenated indexes - even if a composite index is covering for some queries, the engine will have to do only one or two extra lookups .