Spliting Datetime into 2 Columns for Restaurant Reservation Schema?
timestamp vs. date and time
If you are interested in the date part of your timestamp, it is cheaper to just cast it. The result is an actual date, while date_trunc() returns a timestamp! (You could cast that to date in turn, but don't bother.) Your index should be:
CREATE INDEX start_date_index ON reservations (cast(start AS date));

Use the more verbose standard notation cast(column AS type) in the index definition. The Postgres shorthand would require an additional set of parentheses in this context: (column::type). You can still use either notation in queries to match:
SELECT id, start
FROM   reservations
WHERE  start::date = '2014-03-14';

See:

How to create an index on an integer json property in postgres

You can do similar things with start::time if needed.
Either way, I would certainly not split the date and time part. A timestamp is almost always the superior design.
Index tuning
Depending on your actual use cases, you could make that a multi-column index including the id:
CREATE INDEX start_id_date_index ON reservations (cast(start AS date), id);

That would serve the above query perfectly, possibly even with an index-only scan. And since you are now using an actual date in the index (4 bytes), an additional integer column (also 4 bytes) is just perfect for performance. See:

Is a composite index also good for queries on the first field?

What's more, you can also just use a plain index on the timestamp column:
CREATE INDEX start_start_index ON reservations (start);

Just make sure your WHERE conditions are &quot;sargable&quot;. Like:
SELECT id, start
FROM   reservations
WHERE  start &gt;= '2014-03-14 0:0'::timestamp
WHERE  start &lt;  '2014-03-15 0:0'::timestamp;

This will use the index.
The best solution depends on the sum of all your requirements. Also, Postgres can use your original, less optimal index nonetheless. How many rows are there in your table? With only few, a sequential scan is always faster and you won't see an index scan.