This is an attempt at improving Hannah's work around. In her solution, she suggests using 2 indexes on the view and a statistics object.
The 1st index is clustered, which is actually required since unlike a nonclustered index on a table, an error will be generated if creation of a nonclustered index on the view is attempted without first having a clustered index.
The 2nd index is a nonclustered index, which is used as the index behind the query. In the comments section of her answer, I asked what would happen if a clustered index were used instead of a nonclustered index.
The following analysis tries to answer this question.
I'm using the exact same code, except I'm not creating a nonclustered index on the view.
I'm also not creating a statistics object. If you are following along and using SQL Server Management Studio (SSMS) to enter the code below, you should be aware that you may see some red squiggly lines - which look like errors. These are (probably) not errors, but involve an issue with intellisense.
You can either disable intellisense or just ignore the errors and run the commands. They should complete without errors.
-- Create the test table that uses a computed column.
USE tempdb;
CREATE TABLE dbo.PersistedViewTest
(
PersistedViewTest_ID INT NOT NULL
CONSTRAINT PK_PersistedViewTest
PRIMARY KEY CLUSTERED
IDENTITY(1,1)
, SomeData VARCHAR(2000) NOT NULL
, TestComputedColumn AS (PersistedViewTest_ID - 1) PERSISTED
);
GO
-- Insert some test data into the table.
INSERT INTO dbo.PersistedViewTest (SomeData)
SELECT o.name + o1.name + o2.name
FROM sys.objects o
CROSS JOIN sys.objects o1
CROSS JOIN sys.objects o2;
GO
The following execution plan (with no view / index view) is produced after the following query is run against the table:
SELECT pv.PersistedViewTest_ID, pv.TestComputedColumn
FROM dbo.PersistedViewTest pv
WHERE pv.TestComputedColumn = CONVERT(INT, 26)
GO

This gives a baseline to compare against. Notice that after the query completed, a statistics object was created (_WA_Sys_00000003_1FCDBCEB). The PK_PersistedViewTest statistics object was created when the clustered table index was created.
Next, the filtered view and clustered index on that view are created:
-- Create filtered view on the computed column.
CREATE VIEW dbo.PersistedViewTest_View
WITH SCHEMABINDING
AS
SELECT PersistedViewTest_ID, SomeData, TestComputedColumn
FROM dbo.PersistedViewTest
WHERE TestComputedColumn < CONVERT(INT, 27);
GO
-- Create unique clustered index to persist the values, including the computed column.
CREATE UNIQUE CLUSTERED INDEX IX_PersistedViewTest
ON dbo.PersistedViewTest_View(PersistedViewTest_ID);
GO
Now, lets try running the query again, but this time against the view:
SELECT pv.PersistedViewTest_ID, pv.TestComputedColumn
FROM dbo.PersistedViewTest_View pv
WHERE pv.TestComputedColumn = CONVERT(INT, 26)
GO
The new execution plan is now:

If the new plan is to be believed, after the addition of the view and clustered index on that view, the statistics appear to indicate that the time required to execute the query has now doubled. Also, notice that no new statistics object was created to support the new index after the query was run, which is different from the query on the table.
The query plan still suggests that creation of a nonclustered index would be quite helpful in improving the performance of the query. So, does that mean that a nonclustered index has to be added to the view before the desired performance improvement can be obtained? There is one last thing to try. Modify the query to use the "WITH NOEXPAND" option:
SELECT pv.PersistedViewTest_ID, pv.TestComputedColumn
FROM dbo.PersistedViewTest_View pv WITH (NOEXPAND)
WHERE pv.TestComputedColumn = CONVERT(INT, 26)
GO
This results in the following query plan:

This execution plan looks quite similar to the one that was produced with the nonclustered index given in Hannah's answer. But, this one is done with one less (nonclustered) index and one less statistics object.
It turns out that the NOEXPAND option has to be used with the express and standard versions of SQL Server to make proper use of an indexed view. Paul White has an excellent article that expounds on the benefits of using the NOEXPAND option. He also recommends this option be used with the enterprise edition to ensure the uniqueness guarantee provided by the view indexes is used by the optimizer.
The above analysis was done with the express edition of SQL Sever 2014. I also tried it with the developer edition of SQL Server 2016. The NOEXPAND option does not appear to be required with the development edition to achieve the performance gains, but is still recommended.
Less than 5 months ago, Microsoft made the developer editions free. The license restricts the use to development only, which means the database can't be used in a production environment. So, if you have been looking to test out memory optimized tables, encryption, R, etc. then you no longer have the no-license excuse. I successfully installed it on my computer a few days ago along side SQL Server 2014 Express with no issues.
WHERE (sintMarketID = 2 AND strType = 'CARD' AND strTier1 LIKE 'GG%')
though.