The actual view is more complicated and makes selections from table A, as well as a few other tables.

I guess my main curiousity is in regards to the index scans that I'm getting on B. I'm thinking that, given that I'm not being very selective at all on table B, the index scan is probably the best case. That said, is there any benefit to having this index then?

The index is scanned because it is retrieving all the rows in table B. Regarding your question about if the index is useful or not, the proper response would be, "It depends", becuase one of the main advantages of a covering index is that the query do not reach the actual table, for example you have a table with a high row size, definitely the covering index you created would be very useful, however if your table has 6 columns and your covering index has 5 then I don't think it would be useful.

The indexed view can be used in a query execution in two ways. The query can reference the indexed view directly, or, more importantly, the query optimizer can select the view if it determines that the view can be substituted for some or all of the query in the lowest-cost query plan. In the second case, the indexed view is used instead of the underlying tables and their ordinary indexes. The view does not need to be referenced in the query for the query optimizer to use it during query execution. This allows existing applications to benefit from the newly created indexed views without changing those applications

So try it in a non-production DB and check if it performs to your needs.

If everything seems to be going well, you have obviously overlooked something.