Because you can have multiple hash tags per row you obviously can't just use a computed column index. Instead, what you conceptually want to have is an indexed view of the base table cross-applied with a table-valued function that computes the hash tags. I would love to have that in SQL Server, but alas indexed views are extremely limited in what they support. Just forget them for your use case (and look up the restrictions in books online to understand why).
Instead, I recommend that you create a separate table to hold the hash tags (of the form (PostId INT PRIMARY KEY, Tag NVARCHAR(400) PRIMARY KEY, ...
or similar). Maintain that table in the application tier, or using triggers.
You can also maintain the table in a delayed way so that you can do batch updates and do them in the background. That of course means that the app has to tolerate stale data, and it means more development work.