The query is simple enough. It wouldn't be a query per topic, right? Just a single query on the topics in the users' feed and a join on the user_likes table to include that data. It would scale to a considerable degree. Not facebook sized, but fairly large, especially if your indexes were well-constructed.
As far as the number of likes, you could have a counter, but I imagine it could get out of sync if you forget to update the counter at the appropriate times. You might also run into race conditions with this approach if multiple users are liking at the same time. Imagine if two users are liking at the exact same moment. Your typical process would be that an update would read the record to get the most recent number of likes, then increment and update it. However, if both users get the same number, and both increment it, then it would appear as if only one like was added. So, you'd have to solve this potential problem. You're not only dealing with a scale issue, but a timing issue as well.
Perhaps recording the likes to a temporary table or tiny file that a back-end service continuously monitors to update the like numbers might be worth thinking about. This gets into the area of "eventual consistency". A lot to consider on an active, large scale site. I haven't personally done this, so I'm not entirely sure what you'll face. I have done click-tracking for subscription based emails with larger companies, and I can tell you that while this seems easy on the surface, it's really hard to make it perform well at scale.
Deleting the likes could be handled by this back-end service, too. It could be responsible for both incrementing the number and decrementing the number. And while decrementing, simply delete the record from user_likes. Not really sure whether deleting or updating an active/inactive flag is better from a performance standpoint. You'd have to test that out on a very large table with millions of records to see what differences there are.
Since you're using SQL, make sure you account for index fragmentation and have a plan for re-indexing to keep your indexes in optimal condition.