Is a Non-Clustered index needed when referencing a small table with a Foreign Key
Short answer 
No.
Long answer
No, and adding the index could be detrimental to performance.
Something that factors heavily into whether or not a secondary/non-clustered index is even used is how selective it is (and the searches you are trying to perform are).  Y/N has two values - it's ability to be selective is going to depend on the proportion of Y to N.  If they are evenly split, and there is no rhyme/reason to Y/N with relation to the clustered index, they will not be selective and the query optimizer will almost always ignore that index.
The potential slowdown occurs if you issue a delete on the larger table or an update against that Y/N column.  There's no efficient way to update the secondary index as it is organized by Y/N - so the only option is to basically scan the entire index looking for the record to update/delete.  Depending on the number of rows in the main table and the size of the clustered index, this could be an issue.
Caveats
If there are few Ys or few Ns, and you need to locate those records quickly, you can use a filtered index to create a very small index that contains only records for the sparsely populated value.  This can be beneficial and has a much lower footprint than a traditional non-clustered index would in that situation.
If you're just trying to enforce Y/N (or some other easily understood code set), that can be handled easily through a check constraint, which will have a lower overhead than the FK.
ADD CONSTRAINT CK_&lt;ColumnName&gt;_Is_YesNo CHECK (&lt;ColumnName&gt; IN ('Y','N'))