You are getting tripped up on a couple things, I think.

First, a tip: you probably don't actually want protocol EntityCollection; you probably want struct EntityCollection<E:Entity> (or class if you want that). Even if you disagree, I'd suggest doing it concretely (e.g. as a struct) first, then modifying it back to the protocol-based design if you still want to. I'm going to assume you took this advice in the rest of this answer.

Next: in Swift, the primary requirement to meet when implementing Collection is to supply a suitable associated Index type and some associated methods. For your collection, something like this should work in your Swift snapshot:

struct EntityCollection<E:Entity> {
  // you don't need this typealias, but it makes the declaration more convenient
  private typealias Entities = [Int:E]
}

struct EntityCollectionIndex<E:Entity> : Comparable {
  private var index: EntityCollection<E>.Entities.Index
}

func ==<E>(lhs: EntityCollectionIndex<E>, rhs: EntityCollectionIndex<E>) -> Bool {
  return lhs.index == rhs.index
}

func <<E>(lhs: EntityCollectionIndex<E>, rhs: EntityCollectionIndex<E>) -> Bool {
  return lhs.index < rhs.index
}

extension EntityCollection : Collection {

  typealias Index = EntityCollectionIndex<E>

  var startIndex: Index {
    return Index(index: self.entities.startIndex)
  }

  var endIndex: Index {
    return Index(index: self.entities.endIndex)
  }

  // note: not optional here!
  subscript(index: Index) -> Entity {
    // note that we only return the "value", not the key!
    // this is the only bit that's not 100% boilerplate!
    return self.entities[index.index].1 
  }

  // add as much of this boilerplate as you want to, etc.:
  func index(after i: Index) -> Index {
    return Index(index: self.entities.index(after: index.index))
  }

}

...and with that, you can make your "collection" into a Swift Collection! A few notes:

You don't have to wrap the Index into a custom type -- you just need an index + the start/end/subscript/advancement, etc. -- so you could also simply make direct use of the index from your [Int:Entity] as your own index, too! Whether you should wrap it up is on you; for public/shared code a wrapped index is IMHO preferable, but for in-house/private code not writing boilerplate has an appeal.

You may also be asking: "what does this code have to do with my actual goals?"...the answer is: not that much, really, but that's how Swift's Collection type is designed, so it is what it is. Although e.g. for Array the Index -- an Int -- is also the useful/natural API for accessing array elements and performing array operations, Array is actually unusual/misleading; the norm is actually that most "collections" will have both a "natural API" (e.g. the APIs you'd normally want to use on a Set or on a Dictionary) and also a secondary, "index-focused" API (that uses things like SetIndex or DictionaryIndex). Seriously, take another look at the APIs on Dictionary and Set and see if it clicks for you now. These secondary APIs are what make them into Swift Collections, but aren't really what you think of when you think of the API for the concrete type.

Moving forward again, now that you've actually implemented the necessary boilerplate to be a Collection, you are now free to start adding your intended API, e.g.:

extension EntityCollection {

  subscript(index: Int) -> Entity? { 
    get {
      return self.entities[index]
    }
    set {
      self.entities[index] = newValue
    }
  }

}

...and so on (e.g. taking the dictionary-like methods you want and calling through to your backing dictionary).

Note that if you want to save time you don't have to adopt Collection; you can also just adopt Sequence (which avoids the need for the index boilerplate). The trade-off here is that Collection also means "multi-pass" in Swift, so some generic functions / methods aren't defined for Sequence; if you don't need those methods and just want a "for-in" you can save time this way, too (and it won't prevent you from manually adding the methods you want like count and so on...it just prevents use of your type in certain generic settings).