I have found that Brent Ozar Unlimited's free BlitzIndex script (written by Kendra Little) is the best way to isolate unsused indexes (as well as indexes that are beneficial to be added, indexes that are duplicating the work of other indexes etc)
It will tell you the number of times any index has been read since the last time the statistic counts were reset (or an index was created/recreated).
I seem to remember Brent Ozar saying in webcast that a good rule of thumb is no more than 10 indexes for a table that is read often, 20ish for tables that are static/historical/archived data that will not change frequently.
If you are still having issues with import speed is there a time when the database isn't being actively queried (perhaps this is out of office hours). It may be beneficial to drop the index, import the data and then re-apply the indexes. (Statistics will be reset of course.) The reason for this is that the index(es) will be updated as each record goes in, pages will get reordered and that takes time and disk I/O. Building the indexes after requires a single scan of the table.
No hard and fast rule you may have to experiment with this depending on the types of index and the data involved. Indexes should be regularly reviewed as needs/queries change.