Does rowlocks on index cause keylocks? : Transaction (Process ID xy) was deadlocked, example included
Now option "use page locks when accessing the index" caused a lot of
  pagelocks, so it was unchecked


When you play with fire, you get burned. Have you considered what alternative will be used? With page locks disabled, there are two possibilities: use row lock granularity or use rowset granularity. Since there must be at least one row per page, using row granularity will turn into locking at least as many individual locks as page lock, but much more likely more, many many many more locks. So it would turn a bad situation into a far worse situation. Using  rowset granularity will 'heal' the lock manager health as only one lock will be acquired, at the cost of throwing all concurrency down the drain. Do no mess with settings you don't understand. BTW, your question 'do row locks cause key locks' clearly expose the level of your understanding of locking as inadequate to be trusted in changing such important settings, no offense intended.

The important question is why was the query taking page locks? Page locks are the hallmark tellsign of scans: the engine chooses a high granularity because it knows it has a lot of rows to look at. Your post is missing critical information needed to understand the deadlock, please post the entire original deadlock XML, along with the complete schema definition.

As for the question: the 'rowlocks' resource is 'keys' in B-Trees and 'rowids' in heaps.