I see that other answers haven't covered an important aspect of indexes that you may not be familiar with - how indexes work and what they are.
This is obviously an oversimplification, but here's roughly what's going on:
Imagine you have a phone book with 100,000 entries. Each entry has a name, an address, and a phone number. The entries are sorted by names and then by addresses.
When you want to look up the phone number of John Smith in New York, it's fairly easy - you open a random place and see if you're too far in the book or not far enough. Then you take that halve and open that in a random place, etc. Executed perfectly, you only need to examine at most 17 entries before you've found your John.
Now imagine you want to find out who owns the phone number 12345678. You have no other option than to just go through all 100,000 entries and hope to find it.
Something quite similar happens with database tables. All rows in a table are logically sorted by the clustered index (often the primary key), so looking up by that is quick. But if you want to find rows by any other column, SQL Server must examine each and every one of them to find those that match.
This is where indexes come in. Each index is like a mini-table which copies the main table, but the rows are sorted by the indexed columns. Well, OK, an index is not a table, it's actually a special data structure called a "B-tree", which is even more efficient, but you can think of it as a mini-table.
An index doesn't usually contain ALL the columns in the main table - just the ones that are needed for sorting and predicate matching, plus the clustered index columns (if a table doesn't have a clustered index, it uses an internal row identifier instead). When you look things up by an index, SQL Server quickly finds the matching rows in the index and then uses the values in the clustered index columns to quickly find those rows in the main table and get the rest of the data from there.
SQL Server is also smart - if you're only interested in the indexed columns then it might not even touch the main table - it already has all the data it needs in the index itself. And as a developer you can also tell it to include extra columns in the index just for this purpose.
Of course the downside of this is that an index also takes up space and any changes to the main table also need to be reflected in the index (since it needs to be a perfect copy). So more storage used, more RAM used, slower inserts/updates/deletes, but faster selects. It's a trade-off.
This then also answers your question: even if all the rows of the main table fit in RAM, it will still be faster to use an index to look up data, because SQL Server will need to inspect vastly fewer rows. Inspecting 10GB worth of rows is still going to be slow, even if they are all in RAM.