When we're looking up nodes in the graph (as opposed to traversing relationships to connected nodes from nodes already in scope), such as when looking up starting nodes, we utilize some form of lookup depending on what indexes are available and what useful information is present in the query (labels on nodes, predicates on properties, etc).
When we have what we need to perform an index lookup then we'll use that, and that will either be via lucene or our native indexing. If it's lucene, then it's an inverted index of some sort. For our native indexing we're using B-Trees.
Again, this is only for lookup of starting nodes in the graph, or where the planner determines that such a lookup can be used on other nodes in the query and may be more efficient than expansion + filtering. These lookups generally make up a small portion of the query.
The majority of the work when executing a Cypher query is traversing from these nodes via their connected relationships and applying predicates and filtering to find all possible paths matching the given MATCH pattern and WHERE clauses.
It wouldn't make sense to use binary searching when expanding, as the graph itself generally isn't a binary tree, and you typically wouldn't use an entire graph database simply to implement a binary tree.