It's hard to determine when to create a clustered and nonclustered index. There's rarely one sold rule for "this is the best possible way to do this".
A clustered index simply defines the sort order for the data in the table. If I have a table with a clustered index on columnX, SQL Server will store the data physically based on columnX.
A nonclustered index is a seperate object designed to allow SQL Server to more quickly find the data its looking for. It maintains pointers to the physical locations of the data in the table. For instance, if I have a table with 20 columns, but I know that I'll run a lot of queries to search on column3, I can create a nonclustered index on column3. It in turns maintains pointers to the physical location of the actual data in my table. So while column3 might not be stored in order in my table, the query engine can look at my index on column3 really fast and find where individual data is located.
Also, a benefit of nonclustered indexes is that at times you don't even need to hit the physical table for query data. If I have a table called customers and in that table is a column called customer_state (char (2) if you're curious) which contains the 2 digit state abbreviation. I've created a nonclustered index on that column for faster searching. Now I want to know how many customers I have in California. I can execute the following query:
SELECT COUNT(*) FROM customers WHERE customer_state = 'CA'
The query engine doesn't need to go to the physical data store because all the information needed to satisfy the query is located in the index. Because the index only contains the column values and pointers to their physical location, it can be searched much faster (in many cases) than searching the physical data store.
I know this is long winded, but hopefully you understand the difference. There's several decent articles about the subject online, the following seems to be pretty good: